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

["Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>]

> > > 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.

> > 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.

Ian


-------------------------------------------------------
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_ide95&alloc_id396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel