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 13:46, Herbert Xu wrote:

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!

gso_type is a key so the OS (Linux) must deal with all possible values.
Any packet with a protocol or feature bit that it does not recognise
will be dropped.

However, you have a very good point regarding gso_segs.  I'll change it
so that it is always recalculated for SKB_GSO_DODGY packets.

If you can recalculate it, why is the field required at all (both in the skbuff and in the netif_tx_extra)? You previously said it was needed because it can't be recalculated (until you get to the segmentation code, which may be very late in packet processing).

We could calculate gso_segs for TCPv4 in netback, which is all we care about right now.

 -- Keir


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