Re: [PATCH] public/io/netif.h: change semantics of "request-multicast-control" flag

[Paul Durrant <Paul.Durrant@citrix.com>]

> -----Original Message-----
> From: Ian Campbell [mailto:ian.campbell@citrix.com]
> Sent: 20 January 2016 13:06
> To: Paul Durrant; xen-devel@lists.xenproject.org
> Cc: Ian Jackson; Jan Beulich; Keir (Xen.org); Tim (Xen.org)
> Subject: Re: [PATCH] public/io/netif.h: change semantics of "request-
> multicast-control" flag
> 
> On Wed, 2016-01-20 at 12:50 +0000, Paul Durrant wrote:
> > My patch b2700877 "move and amend multicast control documentation"
> > clarified use of the multicast control protocol between frontend and
> > backend. However, it transpires that the restrictions that documentation
> > placed on the "request-multicast-control" flag make it hard for a
> > frontend to enable 'all multicast' promiscuous mode, in that to do so
> > would require the frontend and backend to disconnect and re-connect.
> 
> Do we therefore think that this document reflected reality, i.e. might this
> not be "just" a documentation bug?
> 
> (Or maybe we can't tell because the only previous implementation was years
> ago in Solaris or something)

That's my concern. I hope it's just a documentation bug, but I don't know. Also I've already done an implementation in Linux netback according to the restricted semantics.

> 
> > This patch adds a new "feature-dynamic-multicast-control" flag to allow
> > a backend to advertise that it will watch "request-multicast-control" hence
> > allowing it to be meaningfully modified by the frontend at any time rather
> > than only when the frontend and backend are disconnected.
> 
> Would allowing XEN_NETIF_EXTRA_TYPE_MCAST_{ADD,DEL} to take a bcast
> address
> be easier on the backend, in that it would just need to be a static feature
> rather than watching stuff on the fly?

The documented semantics of the list are 'exact match' so sending a bcast address doesn't do much good with a backend that doesn't know to treat is specially hence a frontend can't tell whether 'all multicast' mode is going to work without the extra feature flag. As for watching "request-multcast-control" vs. add/remove of bcast, the complexity of implementation is cheaper for the latter but I think the former is 'nicer'.

  Paul