Xen devel - Nov 2007 - [PATCH] allow netif frontend to indicate ethernet multicast groups of interest

# HG changeset patch
# User David Edmondson <dme@sun.com>
# Date 1195652069 28800
# Node ID 30a7087e908701deb125f55a004c5841dc6c2165
# Parent  ba69fe2dce91cd7ef633b4b21706344f6be1a6de
Allow multicast address add/remove requests to be passed from the  
frontend
to the backend.

Signed-off-by: David Edmondson <dme@sun.com>

diff --git a/xen/include/public/io/netif.h b/xen/include/public/io/ 
netif.h
--- a/xen/include/public/io/netif.h
+++ b/xen/include/public/io/netif.h
@@ -75,9 +75,11 @@ typedef struct netif_tx_request netif_tx
  typedef struct netif_tx_request netif_tx_request_t;

  /* Types of netif_extra_info descriptors. */
-#define XEN_NETIF_EXTRA_TYPE_NONE  (0)  /* Never used - invalid */
-#define XEN_NETIF_EXTRA_TYPE_GSO   (1)  /* u.gso */
-#define XEN_NETIF_EXTRA_TYPE_MAX   (2)
+#define XEN_NETIF_EXTRA_TYPE_NONE      (0)  /* Never used - invalid */
+#define XEN_NETIF_EXTRA_TYPE_GSO       (1)  /* u.gso */
+#define XEN_NETIF_EXTRA_TYPE_MCAST_ADD (2)  /* u.mcast */
+#define XEN_NETIF_EXTRA_TYPE_MCAST_DEL (3)  /* u.mcast */
+#define XEN_NETIF_EXTRA_TYPE_MAX       (4)

  /* netif_extra_info flags. */
  #define _XEN_NETIF_EXTRA_FLAG_MORE (0)
@@ -118,9 +120,15 @@ struct netif_extra_info {
              uint16_t features; /* XEN_NETIF_GSO_FEAT_* */
          } gso;

+        struct {
+            uint8_t addr[6]; /* Address to add/remove. */
+        } mcast;
+
          uint16_t pad[3];
      } u;
  };
+
+typedef struct netif_extra_info netif_extra_info_t;

  struct netif_tx_response {
      uint16_t id;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

How does a frontend detect whether these options are supported by the
backend? What happens across save/restore? Would this be better implemented
by a multicast list in xenstore?

 -- Keir


On 22/11/07 11:38, "David Edmondson" <dme@sun.com> wrote:
> # HG changeset patch
> # User David Edmondson <dme@sun.com>
> # Date 1195652069 28800
> # Node ID 30a7087e908701deb125f55a004c5841dc6c2165
> # Parent  ba69fe2dce91cd7ef633b4b21706344f6be1a6de
> Allow multicast address add/remove requests to be passed from the
> frontend
> to the backend.
> 
> Signed-off-by: David Edmondson <dme@sun.com>
> 
> diff --git a/xen/include/public/io/netif.h b/xen/include/public/io/
> netif.h
> --- a/xen/include/public/io/netif.h
> +++ b/xen/include/public/io/netif.h
> @@ -75,9 +75,11 @@ typedef struct netif_tx_request netif_tx
>   typedef struct netif_tx_request netif_tx_request_t;
> 
>   /* Types of netif_extra_info descriptors. */
> -#define XEN_NETIF_EXTRA_TYPE_NONE  (0)  /* Never used - invalid */
> -#define XEN_NETIF_EXTRA_TYPE_GSO   (1)  /* u.gso */
> -#define XEN_NETIF_EXTRA_TYPE_MAX   (2)
> +#define XEN_NETIF_EXTRA_TYPE_NONE      (0)  /* Never used - invalid */
> +#define XEN_NETIF_EXTRA_TYPE_GSO       (1)  /* u.gso */
> +#define XEN_NETIF_EXTRA_TYPE_MCAST_ADD (2)  /* u.mcast */
> +#define XEN_NETIF_EXTRA_TYPE_MCAST_DEL (3)  /* u.mcast */
> +#define XEN_NETIF_EXTRA_TYPE_MAX       (4)
> 
>   /* netif_extra_info flags. */
>   #define _XEN_NETIF_EXTRA_FLAG_MORE (0)
> @@ -118,9 +120,15 @@ struct netif_extra_info {
>               uint16_t features; /* XEN_NETIF_GSO_FEAT_* */
>           } gso;
> 
> +        struct {
> +            uint8_t addr[6]; /* Address to add/remove. */
> +        } mcast;
> +
>           uint16_t pad[3];
>       } u;
>   };
> +
> +typedef struct netif_extra_info netif_extra_info_t;
> 
>   struct netif_tx_response {
>       uint16_t id;
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, 2007-11-22 at 14:01 +0000, Keir Fraser wrote:
> How does a frontend detect whether these options are supported by the
> backend? What happens across save/restore? Would this be better implemented
> by a multicast list in xenstore?
A per-guest-vif list in xenstore would also have the advantage that it
would be easily accessible and usable by the network acceleration
modules, without having to republish the add/remove requests from
netback to any registered accelerators.

Kieran


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 22 Nov 2007, at 2:01pm, Keir Fraser wrote:
> How does a frontend detect whether these options are supported by the
> backend?
The backend declares support by setting "feature-multicast-control"  
in xenstore. The frontend indicates that it will use the support by  
setting "request-multicast-control".
> What happens across save/restore?
The frontend is expected to re-add the set it cares about on restore.  
It is not expected to remove the set on suspend.
> Would this be better implemented
> by a multicast list in xenstore?
It seems very messy. The backend will have to watch one or more  
entries in the store, parse them, figure out which are already  
added, ...  The set of multicast address could be large (~100 seems  
feasible). How will the frontend know whether it''s request to add a  
particular entry has been successful?

dme.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 22 Nov 2007, at 2:12pm, Kieran Mansley wrote:
> On Thu, 2007-11-22 at 14:01 +0000, Keir Fraser wrote:
>> How does a frontend detect whether these options are supported by the
>> backend? What happens across save/restore? Would this be better  
>> implemented
>> by a multicast list in xenstore?
>
> A per-guest-vif list in xenstore would also have the advantage that it
> would be easily accessible and usable by the network acceleration
> modules, without having to republish the add/remove requests from
> netback to any registered accelerators.
The best approach for accelerators would seem to depend somewhat on  
the hardware implementation. If the frontend plugin is able to deal  
with the request, there might be no need for the backend plugin to do  
anything.

Having netfront propagate the request to both the frontend plugin and  
the backend (which would relay it to the backend plugin) seems  
straightforward.

Parsing the xenstore entries in more than one place seems like an odd  
approach, particularly as there would ideally be coordination between  
the software driver and the accelerator.

dme.
-- 
David Edmondson, Solaris Engineering, http://dme.org



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 22/11/07 15:34, "David Edmondson" <dme@sun.com> wrote:
> On 22 Nov 2007, at 2:01pm, Keir Fraser wrote:
>> How does a frontend detect whether these options are supported by the
>> backend?
> 
> The backend declares support by setting
"feature-multicast-control"
> in xenstore. The frontend indicates that it will use the support by
> setting "request-multicast-control".
What does the backend do with "request-multicast-control"? Does it
turn off
multicast flooding for this vif?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, 2007-11-22 at 15:40 +0000, David Edmondson
wrote:
> Having netfront propagate the request to both the frontend plugin and  
> the backend (which would relay it to the backend plugin) seems  
> straightforward.
Yes.  My only reason for preferring xenstore is that it doesn''t need a
change to the plugin API, but you''re right that parsing the xenstore
list would likely be more complex than what you''re proposing.

Kieran


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel