Re: [Xen-devel] [PATCH 5/5] xen: Add V4V implementation

[Tim Deegan <tim@xxxxxxx>]

At 17:51 +0100 on 10 Aug (1344621069), Jean Guyader wrote:
> On 09/08 11:38, Tim Deegan wrote:
> > Hi,
> > 
> > This looks pretty good; I think you've addressed almost all my comments
> > except for one, which is really a design decision raether than an
> > implementation one.  As I said last time: 
> > 
> > ] And what about protocol?  Protocol seems to have ended up as a bit of a
> > ] second-class citizen in v4v; it's defined, and indeed required, but not
> > ] used for routing or for acccess control, so all traffic to a given port
> > ] _on every protocol_ ends up on the same ring. 
> > ] 
> > ] This is the inverse of the TCP/IP namespace that you're copying, where
> > ] protocol demux happens before port demux.  And I think it will bite
> > ] someone if you ever, for example, want to send ICMP or GRE over a v4v
> > ] channel.
> > 
> 
> The protocol field is used to inform about the type a message on the ring.
> 
> Right now we use two protocols in our linux driver: V4V_PROTO_DGRAM and
> V4V_PROTO_STREAM. In the future that could probably be extended to new 
> protocol
> like V4V_PROTO_ICMP for instance.
> 
> The demultiplexing will happens at the other end, the driver can look at the
> message and decide what to do with it based on the protocol field.

Yes, I understand all that - what I'm saying is that it seems like a
design flaw to me.  The namespace in V4V, as proposed, looks like this:

 Protocol
 Port
 Domain

and it would be more sensible to do (like the IP stack):

 Port
 Protocol
 Domain.

Or at the very least the protocol should be made part of the endpoint
address, and not just part of the packet header.  As it stands:

 - The handlers for port X in _all_ protocols _have_ to share a
   ring.  That seems kind of plausible because the IANA port assignments
   never give the same port number to different services on TCP and UDP,
   but will it make sense for every new protocol?  Is it sensible to
   require, say, an L2TP service to make its connection IDs not clash
   with V4V_PROTO_DGRAM and V4V_PROTO_STREAM users?

   It may not even make sense in existing protocols.  It's common enough
   for DNS servers to use different ACLs (and indeed different servers)
   for TCP and UDP.

 - Relatedly, every protocol _has_ to have port numbers.  How would you
   register an ICMP listener, for example?  You'd have to do something
   gross like declare a particular port to be the ICMP port so that you
   could demux it, or indeed send it in the first place.

You say:

> The demultiplexing will happens at the other end, the driver can look at the
> message and decide what to do with it based on the protocol field.

I'm willing to accept that argument, but only if we extend it to ports
too, get rid of all the namespace and ACL code in Xen and leave each
domain with a single RX ring that the (single) guest driver must demux. :P

Cheers,

Tim.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel