Re: Headroom for bridging and wireless

Bart De Schuymer <[email protected]>
Newsgroups gmane.linux.network.bridge.ebtables.devel
Message-ID <[email protected]>
On Monday 08 December 2003 20:59, Tom Marshall wrote:
> > Your patch to br_if.c does seem to use an uninitialized p pointer.
>
> I'm afraid that I am not familiar with the kernel list functions.  It was
> an ugly copy/paste job.  ;-)

Oops, I was wrong.

> > Apart from that, I've just changed the hard_header_len for my bridge box
> > and the headroom did increase as it should, for packets originating from
> > the bridge and going through br0.
>
> Nice, but it would be most useful to have the bridged packets use the
> increased headroom.  I don't suppose there is a way to do that easily.  The
> only thing I can think of right now is to have the skb functions always
> reserve the maximum headroom for all devices in the system.  Seems a small
> price to pay for a huge decrease in reallocs.
> Note this is not just a bridge problem, it should also apply to routing.

I see include/linux/skbuff.h::__dev_alloc_skb() already allocates 16 more 
bytes than needed. When looking at my own bridge box's head, data and mac.raw 
skbuff pointers for bridged frames, they seem to always have 16 (well, 18) 
bytes of spare space to play with. So, I think the only skbuffs that need a 
realloc are those not allocated with dev_alloc_skb().
Looks like in my case only the packets originating from the bridge box itself 
don't have this extra 16 bytes head room. But that should be fixed with your 
bridge patch.
I'm not too familiar with these low level details, however.

cheers,
Bart



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.