[Xen-devel] Re: [1/4] [NET] back: Fix maximum fragment check

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 30 Jun 2006, at 13:47, Herbert Xu wrote:

> The net-tso patch has been merged upstream.  I've also changed the
> feature-tso interface to be a bit mask of the XEN gso_types bits.
> It's now called feature-gso.  This means we won't have to add one
> feature for each protocol.
>
> So here is a repost of the entire series.
I've merged all this already, with a few changes. I've also disabled 
netback from advertising the feature, and also netfront from using it, 
until we've all agreed that the inter-domain bits are sane. These 
should end up in the public tree in an hour or two.
The changes:
 1. Pushed the gso fields into a struct inside the union. Otherwise the 
fields overlap.
 2. Changed the GSO type definitions. Currently only one type (TCPv4) 
and the protocol type isn't really a bitmask since they are mutually 
exclusive for a given packet. Also 'dodgy' makes no sense since netback 
doesn't trust netfront anyway.
 3. Renamed TXTRA->EXTRA and tx_extra -> extra_info. Looks like you 
want to share the struct with the rx patch at some point, so making it 
tx-specific now makes no sense. If that's not the case we can rename 
back again.
 4. I'm not sure all the error paths are now correct in netback. For 
example, there's a call to netbk_tx_err with an end index of 0. Is that 
right?
In the latest changes I'd rather have feature-gso list the supported 
protocols as strings (tcpv4,udpv4,etc).
Also, what happens if netfront does the following bad things:
 1. gso.type doesn't actually match the protocol type?
 2. gso.size is set to a really small value (so that you make lots of 
packets)?
Do we need more handling of these cases in netback? Will these be 
safely handled in the network stack? Might we need to always work out 
gso.type in netback for safety?
 -- Keir


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