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