From: Ian Campbell <ian.campbell@citrix.com>
To: Paul Durrant <paul.durrant@citrix.com>, xen-devel@lists.xenproject.org
Cc: Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>,
Ian Jackson <ian.jackson@eu.citrix.com>,
Jan Beulich <jbeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>,
Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH] public/io/netif.h: change semantics of "request-multicast-control" flag
Date: Thu, 21 Jan 2016 15:29:36 +0000 [thread overview]
Message-ID: <1453390176.4320.47.camel@citrix.com> (raw)
In-Reply-To: <1453294249-6346-1-git-send-email-paul.durrant@citrix.com>
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.
>
> 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.
>
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Keir Fraser <keir@xen.org>
> Cc: Tim Deegan <tim@xen.org>
This looks good to me, but also adding Wei (Linux netback + BSD stuff) and
Roger (BSD stuff) for their perspective.
I should probably have done that for the last set of netif.h changes too,
since apart from the nominal maintainers of xen/include/public/io/*.h it's
worth getting input from the maintainers of the consumers. Not sure we can
express that very well in MAINTAINERS :-(.
Ian.
> ---
> xen/include/public/io/netif.h | 34 ++++++++++++++++++++++------------
> 1 file changed, 22 insertions(+), 12 deletions(-)
>
> diff --git a/xen/include/public/io/netif.h
> b/xen/include/public/io/netif.h
> index fe0a87f..8816e0f 100644
> --- a/xen/include/public/io/netif.h
> +++ b/xen/include/public/io/netif.h
> @@ -136,18 +136,28 @@
> */
>
> /*
> - * "feature-multicast-control" advertises the capability to filter ethernet
> - * multicast packets in the backend. To enable use of this capability the
> - * frontend must set "request-multicast-control" before moving into the
> - * connected state.
> - *
> - * If "request-multicast-control" is set then the backend transmit side should
> - * no longer flood multicast packets to the frontend, it should instead drop any
> - * multicast packet that does not match in a filter list. The list is
> - * amended by the frontend by sending dummy transmit requests containing
> - * XEN_NETIF_EXTRA_TYPE_MCAST_{ADD,DEL} extra-info fragments as specified below.
> - * Once enabled by the frontend, the feature cannot be disabled except by
> - * closing and re-connecting to the backend.
> + * "feature-multicast-control" and "feature-dynamic-multicast-control"
> + * advertise the capability to filter ethernet multicast packets in the
> + * backend. If the frontend wishes to take advantage of this feature then
> + * it may set "request-multicast-control". If the backend only advertises
> + * "feature-multicast-control" then "request-multicast-control" must be set
> + * before the frontend moves into the connected state. The backend will
> + * sample the value on this state transition and any subsequent change in
> + * value will have no effect. However, if the backend also advertises
> + * "feature-dynamic-multicast-control" then "request-multicast-control"
> + * may be set by the frontend at any time. In this case, the backend will
> + * watch the value and re-sample on watch events.
> + *
> + * If the sampled value of "request-multicast-control" is set then the
> + * backend transmit side should no longer flood multicast packets to the
> + * frontend, it should instead drop any multicast packet that does not
> + * match in a filter list.
> + * The list is amended by the frontend by sending dummy transmit requests
> + * containing XEN_NETIF_EXTRA_TYPE_MCAST_{ADD,DEL} extra-info fragments as
> + * specified below.
> + * Note that the filter list may be amended even if the sampled value of
> + * "request-multicast-control" is not set, however the filter should only
> + * be applied if it is set.
> */
>
> /*
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-01-21 15:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-20 12:50 [PATCH] public/io/netif.h: change semantics of "request-multicast-control" flag Paul Durrant
2016-01-20 13:06 ` Ian Campbell
2016-01-20 13:14 ` Paul Durrant
2016-01-21 11:48 ` Paul Durrant
2016-01-21 11:59 ` Ian Campbell
2016-01-21 12:00 ` Paul Durrant
2016-01-21 15:29 ` Ian Campbell [this message]
2016-01-21 15:35 ` Roger Pau Monné
2016-01-21 15:46 ` Wei Liu
2016-01-21 15:45 ` Wei Liu
2016-01-26 14:17 ` Paul Durrant
2016-01-26 16:51 ` Ian Campbell
2016-01-27 14:22 ` Paul Durrant
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1453390176.4320.47.camel@citrix.com \
--to=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jbeulich@suse.com \
--cc=keir@xen.org \
--cc=paul.durrant@citrix.com \
--cc=roger.pau@citrix.com \
--cc=tim@xen.org \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).