| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[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
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
|
|
|
| |
|
Home