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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.