[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [bluetooth-dev] it's so big

> On Tue, 13 Mar 2001, Gordon McNutt wrote:
> > >    could instead be allocated dynamically for each new active
> > >    (non parked/hold) hci handle.
> > 
> > Have you ever considered using sk_bufs? I'm not too 
> familiar with Linux
> > networking internals, but I know on some embedded OS's the 
> kernel already keeps
> > a pool of buffers for networks. This idea also applies to 
> your comment about
> The skbuf's are just an interface for passing data in the 
> network-stack,
> there is nothing different really about an allocation of an 
> skbuf than a
> chunk of memory (there is no pool of skbufs and there are 
> reasons why this
> is not desirable). There are some helper abstractions for 
> shrinking and
> growing to remove/fit headers and stuff but I'm not sure that would be
> useful for your hci buffers. If you need dynamic memory, a 
> simple kmalloc
> would do fine for this I'm sure.

The idea was not to use skbufs for the hci inbuffers, here kmalloc 
will do fine, but when when sending data 'down' in the stack rfcomm->l2cap->hci,
skbufs might be a nicer solution instead of using btmem (see btmem.c).

> When the IP over L2CAP system works, you'd certainly want to 
> hook the BT
> driver into the network stack to send up/down IP packets in 
> skbufs though.
> -BW

Wouldn't it be nice if we could use skbufs all the way from IP down to HCI ?

To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com