[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.