From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Durrant Subject: Re: [PATCH] public/io/netif.h: change semantics of "request-multicast-control" flag Date: Thu, 21 Jan 2016 11:48:34 +0000 Message-ID: <2b608c79a7e24639bedbfc99f35d25e1@AMSPEX02CL03.citrite.net> References: <1453294249-6346-1-git-send-email-paul.durrant@citrix.com> <1453295177.26343.115.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aMDjB-000866-5j for xen-devel@lists.xenproject.org; Thu, 21 Jan 2016 11:48:37 +0000 In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Paul Durrant , Ian Campbell , "xen-devel@lists.xenproject.org" Cc: Ian Jackson , "Keir (Xen.org)" , Jan Beulich , "Tim (Xen.org)" List-Id: xen-devel@lists.xenproject.org > -----Original Message----- > From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- > bounces@lists.xen.org] On Behalf Of Paul Durrant > Sent: 20 January 2016 13:14 > To: Ian Campbell; xen-devel@lists.xenproject.org > Cc: Ian Jackson; Keir (Xen.org); Jan Beulich; Tim (Xen.org) > Subject: Re: [Xen-devel] [PATCH] public/io/netif.h: change semantics of > "request-multicast-control" flag > > > -----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'. > Are you ok with the xenstore watch approach (and leaving the patch as is) or would you prefer to spec. the bcast address as a wildcard and submit a new patch? Paul > Paul > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel