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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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
> strings.
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?
 Thanks!
 Keir


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