[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOrHB_AO_bBc7sHkK=JrQBxHMztr5vK8n1Hj-_COe7a7SCDg_A@mail.gmail.com>
Date: Sat, 20 Jan 2018 21:52:43 -0800
From: Pravin Shelar <pshelar@....org>
To: William Tu <u9012063@...il.com>
Cc: Linux Kernel Network Developers <netdev@...r.kernel.org>,
Jiri Benc <jbenc@...hat.com>
Subject: Re: [PATCHv4 net-next 2/2] openvswitch: add erspan version I and II support
On Thu, Jan 18, 2018 at 2:04 PM, William Tu <u9012063@...il.com> wrote:
> The patch adds support for openvswitch to configure erspan
> v1 and v2. The OVS_TUNNEL_KEY_ATTR_ERSPAN_OPTS attr is added
> to uapi as a nested attribute to support all ERSPAN v1 and v2's
> fields. Note taht Previous commit "openvswitch: Add erspan tunnel
> support." was reverted since it does not design properly.
>
> Signed-off-by: William Tu <u9012063@...il.com>
> ---
> include/uapi/linux/openvswitch.h | 11 +++
> net/openvswitch/flow_netlink.c | 154 ++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 164 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/openvswitch.h b/include/uapi/linux/openvswitch.h
> index dcfab5e3b55c..f1f98fd703fe 100644
> --- a/include/uapi/linux/openvswitch.h
> +++ b/include/uapi/linux/openvswitch.h
> @@ -273,6 +273,16 @@ enum {
>
> #define OVS_VXLAN_EXT_MAX (__OVS_VXLAN_EXT_MAX - 1)
>
> +enum {
> + OVS_ERSPAN_OPT_UNSPEC,
> + OVS_ERSPAN_OPT_IDX, /* u32 index */
> + OVS_ERSPAN_OPT_VER, /* u8 version number */
> + OVS_ERSPAN_OPT_DIR, /* u8 direction */
> + OVS_ERSPAN_OPT_HWID, /* u8 hardware ID */
> + __OVS_ERSPAN_OPT_MAX,
> +};
> +
> +#define OVS_ERSPAN_OPT_MAX (__OVS_ERSPAN_OPT_MAX - 1)
>
> /* OVS_VPORT_ATTR_OPTIONS attributes for tunnels.
> */
> @@ -363,6 +373,7 @@ enum ovs_tunnel_key_attr {
> OVS_TUNNEL_KEY_ATTR_IPV6_SRC, /* struct in6_addr src IPv6 address. */
> OVS_TUNNEL_KEY_ATTR_IPV6_DST, /* struct in6_addr dst IPv6 address. */
> OVS_TUNNEL_KEY_ATTR_PAD,
> + OVS_TUNNEL_KEY_ATTR_ERSPAN_OPTS, /* Nested OVS_ERSPAN_OPT_* */
> __OVS_TUNNEL_KEY_ATTR_MAX
> };
>
Rather than passing individual members of erspan_metadata, can you
just pass whole structure between kernel and userspace. So that ovs
kernel module can just handle all erspan options as one binary blob
and does not need to interpret it.
Powered by blists - more mailing lists