| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] [PATCH 2/2] netfront skb padding
> > > 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
|
|
|
| |
|
Home