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

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

On Fri, Jun 30, 2006 at 02:07:16PM +0100, Keir Fraser wrote:
>
> 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.

Thanks.

> The changes:
>  1. Pushed the gso fields into a struct inside the union. Otherwise the 
> fields overlap.

Doh! Thanks for the correction.

>  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.

Agreed wrt 'dodgy' bit.

However, this really needs to be a bit mask because we'll have things
like ECN and other protocol-specific bits in future.  In fact the
upstream Linux tree has an ECN bit now.

The exclusivity will be checked by Linux (I've already submitted patches
to do this).

>  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.

Yes that's the plan.

>  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?

That was deliberate as 0 is the smallest RING_IDX.  However, now that
I look at it again there is an off-by-one bug.  I'll fix that tomorrow.

> In the latest changes I'd rather have feature-gso list the supported 
> protocols as strings (tcpv4,udpv4,etc).

Well then I might as well go back to the one int per-bit thing with
'feature-tso', 'feature-ufo', etc.  It's much easier than parsing
strings.

> Also, what happens if netfront does the following bad things:
>  1. gso.type doesn't actually match the protocol type?

This is checked by Linux due to the 'dodgy' bit.  The code isn't in
the net-gso patch yet because for now it only has one protocol.
The upstream code should have it tomorrow as we're about to add TSO6.

>  2. gso.size is set to a really small value (so that you make lots of 
> packets)?

That's OK.  TCP must deal with an MSS of 1 anyway.  The same applies to
the other protocols.

> 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?

I think we've got all the bits covered now.  But if you can think of
anything else please let me know.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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