From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH] public/io/netif.h: change semantics of "request-multicast-control" flag Date: Wed, 20 Jan 2016 13:06:17 +0000 Message-ID: <1453295177.26343.115.camel@citrix.com> References: <1453294249-6346-1-git-send-email-paul.durrant@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aLsTN-0000RO-RR for xen-devel@lists.xenproject.org; Wed, 20 Jan 2016 13:06:53 +0000 In-Reply-To: <1453294249-6346-1-git-send-email-paul.durrant@citrix.com> 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 , xen-devel@lists.xenproject.org Cc: Keir Fraser , Ian Jackson , Jan Beulich , Tim Deegan List-Id: xen-devel@lists.xenproject.org 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) > 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?