[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |