On Fri, 11 Aug 2017 09:24:25 +0000, Yang, Yi Y wrote:
> So far, we're not clear how we can support MD type 2 better, as I
> explained before, we need to reuse tun_metadata in struct flow_tnl
> which is the thing Geneve is using. Geneve predefined 64 keys for
> this from tun_metadata0 to tun_metadata63, we will reuse it for MD
> type 2. But you know NSH is not tunnel, so it has to be changed to
> support both Geneve and NSH. Anyway, they won't be part of
> ovs_key_nsh.
Please do not top post.
The context field does not apply to MD type 2. It looks wrong for the
context field to be included in netlink attribute for anything other
than MD type 1. Perhaps it needs to be put into a separate attribute,
too?
Note that I'm talking only about the uAPI. Internally, ovs can use
struct ovs_key_nsh that is MD type 1 only, there's no problem changing
that later. But for the user space interface, this needs to be clean.
This can be solved for example this way:
In include/uapi/linux/openvswitch.h:
struct ovs_key_nsh_base {
__u8 flags;
__u8 mdtype;
__u8 np;
__u8 pad;
__be32 path_hdr;
};
+ one more netlink attribute carrying MD type 1 info. Will probably
require to change OVS_KEY_ATTR_NSH to a nested attribute etc.
In net/openvswitch/flow.h (or perhaps a different header would be more
appropriate?):
struct ovs_key_nsh {
struct ovs_key_nsh_base base;
__be32 context[4];
};
Plus needed conversions between OVS_KEY_ATTR_NSH and struct ovs_key_nsh
when interfacing between the kernel and user space.
That way, we can have MD type 1 support only for now while still being
allowed to redesign things in whatever way later.
Jiri
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
