WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [0/5] [NET]: Add TSO support


On 29 Jun 2006, at 10:40, Herbert Xu wrote:

On Thu, Jun 29, 2006 at 10:02:20AM +0100, Keir Fraser wrote:

For TSO, gso_segs can be easily determined from the packet and
gso_size.
However, for GSO, we don't know the packet header length so the same is
not true.

Each segment will need a header though, I'd imagine, so whoever does
the segmentation needs to know the packet header length? Maybe I'm just

The code or chip that actually does the segmentation will obviously
know the header length.  However, netback or netfront does not.

Since Linux requires gso_segs to be set (it's used to figure out how
many packets there are going to be before segmentation takes place),
we really need to set it at the source where the packet is produced.

For another OS that only supports TSO, they would simply have to set
gso_segs in the frontend driver.

What if gso_segs, or any other gso parameter (e.g., type), is set incorrectly? The backend cannot trust frontend clients, so I'm rather worried that we could make the backend network stack crash!

Also we should probably only define a XEN_GSO_TCPV4 flag for now, since we support only plain TSO right now. No skbuffs should get passed to netfront that have other GSO flags set, right? Seince we only advertise NETIF_F_TSO.

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel