Re: [Xen-devel] [PATCH 2/2] netfront skb padding

[Jon Mason <jdmason@xxxxxxxxxx>]

On Wednesday 09 February 2005 11:26 am, Ian Pratt wrote:
> > > > It appears that when alloc'ing a skb, it is bring padded by 
> > > > an arbitrarily 
> > > > (and excessive) long value.  The value for this padding 
> > > > really only needs to 
> > > > be 24.  24 = 14 for the ethernet header + 2 for the cache 
> > > > alignment + 4 for 
> > > > the CRC + 4 for the VLAN flags.
> > > 
> > > Given that we're allocating page sized buffers the current situation
> > > doesn't cost us anything.
> > 
> > Unless it starts using larger packets, e.g. Jumbo Frames 
> > (hint hint).  Then
> > the unnecessary room can be a problem, as the unnecessary pad 
> > could cause the
> > unnecessary allocation of an extra page.
> 
> How? Ethernet packets are circa 1500 bytes, and we allocate a 4K page
> for each so that we can page flip them.

Jumbo frames can be 16k (or possibly larger), that would be 4 pages + 1 
unnecessary page containing the 200 bytes.
 
> > > Infact, what happens if the packet gets encapsulated e.g. by etherip
> > > etc? Is Linux smart enough to be able to put the extra headers on
> > > in-place if there is enough head room?
> > 
> > I would assume that they would have to be there.
> 
> They wouldn't have to be, because Linux could just copy the packet, into
> a new skb, but I believe it could use skb pull etc to see if it could
> allocate space for headers on the front of the packet. In which case,
> having more headroom would be a good thing.

Sure, but we only have 1 layer (not the 9 that we have room for).  All other 
layers would be encapsulated inside the data of the skb (or am I not 
understanding the problem correctly).


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel