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

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

On 30 Jun 2006, at 14:21, Herbert Xu wrote:

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

I'm not at all bothered about having the type format the same as in Linux. How about we split the type into protocol (being a proper enumeration) and proto_flags (being a protocol-specific bitmask)? Might there be any non-proto-specific flags in future?

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

I'm not too bothered either way, but I personally prefer having the more properly qualified names listed under feature-gso. Pulling it apart with strstr() in netfront (for each proto that netfront can deal with) wouldn't be hard.

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.

Do we then need the 'type' at all? What is it actually used for -- I'd assume the network stack would demux to the correct protocol code as it would for any ordinary packet, so why does it need help with the protocol for GSO packets?


Xen-devel mailing list



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