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

 > How could their be more than one layer of encapsulation 
> greater than MTU?  
> When the packet comes into dom0, it is already <= MTU.  It 
> gets encapsulated
> with another layer of routing data, and sent to its 
> destination.  So, it is 
> at maximum size MTU+24.

Dom0 may want to put extra headers on the *front* of the packet. By
having the packet starting a fair way in to the data area of the skb it
should be possible to add them in the same data area rather than create
pre-pend another fragement.

Anyhow, the current situation doesn't really waste any memory because
skb data areas are all whole pages.

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

<Prev in Thread]

Current Thread

[Next in Thread>

Previous by Date:

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

Next by Date:

Re: [Xen-devel] [PATCH 1/2] netfront coding style clean-up (trivial), Ian Pratt

Previous by Thread:

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

Next by Thread:

[Xen-devel] xend silently fails to start (but it starts xfrd), no error in xend.log, Kero-Chan

Indexes:

[Date] [Thread] [Top] [All Lists]