Re: [ovs-dev] [PATCH v2 1/1] netdev-vport: reject concomitant incompatible tunnels
On Wed, May 09, 2018 at 04:41:05PM +0200, Eelco Chaudron wrote: > On 13/04/18 20:02, Ben Pfaff wrote: > >On Fri, Feb 09, 2018 at 03:42:56PM +0100, Eelco Chaudron wrote: > >>This patch will make sure VXLAN tunnels with and without the group > >>based policy (GBP) option enabled can not coexist on the same > >>destination UDP port. > >> > >>In theory, VXLAN tunnel with and without GBP enables can be > >>multiplexed on the same UDP port as long as different VNI's are > >>used. However currently OVS does not support this, hence this patch to > >>check for this condition. > >> > >>v1->v2 > >> Updated commit message as its now clear that the OVS implementation > >> does not support VNI multiplexing on the same UDP port. > >> > >>Signed-off-by: Eelco Chaudron > >Thanks for the update. > > > >Doesn't this make tunnel configuration O(n**2) in the number of tunnels? > >It looks like every tunnel checks at configuration time whether there is > >another tunnel of the same kind. I know of some configurations with > >hundreds (thousands?) of tunnels. Is there a way to make it cheaper? > > > > Thanks for the reply, and sorry for the late response, as this was on my low > priority stack... > > I looked at it again and you are right this is an expensive operation with a > lot of tunnels, especially with the smap creation. > > It looks like Cascardo's original patch with a simap per port might be less > expensive. However, he forgot the cleanup and with his approach, we need to > walk all tunnels to make sure this is the last tunnel and we can remove the > simap entry. I could do a shash and keep a tunnel count to avoid the cleanup > walk. Or maybe some other way to quickly find the vport with a hmap... > > I'll investigate the options a bit more and come with a v3. Thanks for taking a look. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2 1/1] netdev-vport: reject concomitant incompatible tunnels
On 13/04/18 20:02, Ben Pfaff wrote: On Fri, Feb 09, 2018 at 03:42:56PM +0100, Eelco Chaudron wrote: This patch will make sure VXLAN tunnels with and without the group based policy (GBP) option enabled can not coexist on the same destination UDP port. In theory, VXLAN tunnel with and without GBP enables can be multiplexed on the same UDP port as long as different VNI's are used. However currently OVS does not support this, hence this patch to check for this condition. v1->v2 Updated commit message as its now clear that the OVS implementation does not support VNI multiplexing on the same UDP port. Signed-off-by: Eelco Chaudron Thanks for the update. Doesn't this make tunnel configuration O(n**2) in the number of tunnels? It looks like every tunnel checks at configuration time whether there is another tunnel of the same kind. I know of some configurations with hundreds (thousands?) of tunnels. Is there a way to make it cheaper? Thanks for the reply, and sorry for the late response, as this was on my low priority stack... I looked at it again and you are right this is an expensive operation with a lot of tunnels, especially with the smap creation. It looks like Cascardo's original patch with a simap per port might be less expensive. However, he forgot the cleanup and with his approach, we need to walk all tunnels to make sure this is the last tunnel and we can remove the simap entry. I could do a shash and keep a tunnel count to avoid the cleanup walk. Or maybe some other way to quickly find the vport with a hmap... I'll investigate the options a bit more and come with a v3. Cheers, Eelco ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2 1/1] netdev-vport: reject concomitant incompatible tunnels
On Fri, Feb 09, 2018 at 03:42:56PM +0100, Eelco Chaudron wrote: > This patch will make sure VXLAN tunnels with and without the group > based policy (GBP) option enabled can not coexist on the same > destination UDP port. > > In theory, VXLAN tunnel with and without GBP enables can be > multiplexed on the same UDP port as long as different VNI's are > used. However currently OVS does not support this, hence this patch to > check for this condition. > > v1->v2 > Updated commit message as its now clear that the OVS implementation > does not support VNI multiplexing on the same UDP port. > > Signed-off-by: Eelco Chaudron Thanks for the update. Doesn't this make tunnel configuration O(n**2) in the number of tunnels? It looks like every tunnel checks at configuration time whether there is another tunnel of the same kind. I know of some configurations with hundreds (thousands?) of tunnels. Is there a way to make it cheaper? Thanks, Ben. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2 1/1] netdev-vport: reject concomitant incompatible tunnels
Any feedback on this patch? On 09/02/18 15:42, Eelco Chaudron wrote: This patch will make sure VXLAN tunnels with and without the group based policy (GBP) option enabled can not coexist on the same destination UDP port. In theory, VXLAN tunnel with and without GBP enables can be multiplexed on the same UDP port as long as different VNI's are used. However currently OVS does not support this, hence this patch to check for this condition. v1->v2 Updated commit message as its now clear that the OVS implementation does not support VNI multiplexing on the same UDP port. Signed-off-by: Eelco Chaudron --- lib/netdev-vport.c | 97 -- tests/tunnel.at| 29 2 files changed, 108 insertions(+), 18 deletions(-) diff --git a/lib/netdev-vport.c b/lib/netdev-vport.c index 52aa12d79..bc8226d62 100644 --- a/lib/netdev-vport.c +++ b/lib/netdev-vport.c @@ -66,11 +66,13 @@ static uint64_t rt_change_seqno; static int get_patch_config(const struct netdev *netdev, struct smap *args); static int get_tunnel_config(const struct netdev *, struct smap *args); static bool tunnel_check_status_change__(struct netdev_vport *); +static const struct vport_class *netdev_vport_get_class_by_name(const char *); struct vport_class { const char *dpif_port; struct netdev_class netdev_class; }; +static const struct vport_class vport_classes[]; bool netdev_vport_is_vport_class(const struct netdev_class *class) @@ -421,6 +423,43 @@ default_pt_mode(enum tunnel_layers layers) return layers == TNL_L3 ? NETDEV_PT_LEGACY_L3 : NETDEV_PT_LEGACY_L2; } +static bool +is_concomitant_vxlan_tunnel_present(struct netdev_vport *dev, +const struct netdev_tunnel_config *tnl_cfg) { +bool is_present = false; +struct shash device_shash; +struct shash_node *node; +const char *type = netdev_get_type(&dev->up); +const struct vport_class *vport_class; + +if (strcmp(type, "vxlan")) { +return false; +} + +shash_init(&device_shash); +vport_class = netdev_vport_get_class_by_name("vxlan"); +ovs_assert(vport_class); + +netdev_get_devices(&vport_class->netdev_class, &device_shash); + +SHASH_FOR_EACH (node, &device_shash) { +struct netdev *netdev_ = node->data; +struct netdev_vport *netdev = netdev_vport_cast(netdev_); + +if (netdev != dev && +tnl_cfg->dst_port == netdev->tnl_cfg.dst_port && +(tnl_cfg->exts & (1 << OVS_VXLAN_EXT_GBP)) != +(netdev->tnl_cfg.exts & (1 << OVS_VXLAN_EXT_GBP))) { +is_present = true; +} +netdev_close(netdev_); +} + +shash_destroy(&device_shash); + +return is_present; +} + static int set_tunnel_config(struct netdev *dev_, const struct smap *args, char **errp) { @@ -614,6 +653,15 @@ set_tunnel_config(struct netdev *dev_, const struct smap *args, char **errp) &tnl_cfg.out_key_present, &tnl_cfg.out_key_flow); +if (is_concomitant_vxlan_tunnel_present(dev, &tnl_cfg)) { +ds_put_format(&errors, "%s: VXLAN-GBP, and non-VXLAN-GBP " + "tunnels can't be configured on the same " + "dst_port\n", + name); +err = EEXIST; +goto out; +} + ovs_mutex_lock(&dev->mutex); if (memcmp(&dev->tnl_cfg, &tnl_cfg, sizeof tnl_cfg)) { dev->tnl_cfg = tnl_cfg; @@ -959,27 +1007,40 @@ netdev_vport_get_ifindex(const struct netdev *netdev_) BUILD_HEADER, PUSH_HEADER, POP_HEADER, \ GET_IFINDEX) }} +/* The name of the dpif_port should be short enough to accomodate adding + * a port number to the end if one is necessary. */ +static const struct vport_class vport_classes[] = { +TUNNEL_CLASS("geneve", "genev_sys", netdev_geneve_build_header, +netdev_tnl_push_udp_header, +netdev_geneve_pop_header, +NETDEV_VPORT_GET_IFINDEX), +TUNNEL_CLASS("gre", "gre_sys", netdev_gre_build_header, + netdev_gre_push_header, + netdev_gre_pop_header, + NULL), +TUNNEL_CLASS("vxlan", "vxlan_sys", netdev_vxlan_build_header, + netdev_tnl_push_udp_header, + netdev_vxlan_pop_header, + NETDEV_VPORT_GET_IFINDEX), +TUNNEL_CLASS("lisp", "lisp_sys", NULL, NULL, NULL, NULL), +TUNNEL_CLASS("stt", "stt_sys", NULL, NULL, NULL, NULL), +}; + +static const struct vport_class * +netdev_vport_get_class_by_name(const char *name) { +int i; + +for (i = 0; i < ARRAY_SIZE(vport_classes); i++) { +