| Message ID | 1438753867-32403-1-git-send-email-ast@plumgrid.com |
|---|---|
| State | Accepted, archived |
| Delegated to: | David Miller |
| Headers | show |
On 08/04/15 at 10:51pm, Alexei Starovoitov wrote: > IFLA_VXLAN_FLOWBASED is useless without IFLA_VXLAN_COLLECT_METADATA, > so combine them into single IFLA_VXLAN_COLLECT_METADATA flag. > 'flowbased' doesn't convey real meaning of the vxlan tunnel mode. > This mode can be used by routing, tc+bpf and ovs. > Only ovs is strictly flow based, so 'collect metadata' is a better > name for this tunnel mode. > > Signed-off-by: Alexei Starovoitov <ast@plumgrid.com> I have no objection since a flag to enable tx only can be added again if needed. As stated in the other thread, the tx only mode which is what VXLAN was capable of doing so far is what motivated the split of flags. Acked-by: Thomas Graf <tgraf@suug.ch> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 8/5/15 7:42 AM, Thomas Graf wrote: > I have no objection since a flag to enable tx only can be added again if > needed. As stated in the other thread, the tx only mode which is what > VXLAN was capable of doing so far is what motivated the split of flags. I see the intent. A bit confusing though, since today FLOWBASED affects pieces of TX and RX and COLLECT_METADATA another piece of RX. After the patch COLLECT_METADATA does it all. imo cleaner. but yeah, as you said, we can add 'tx only' later if really needed. thanks for review! -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Alexei Starovoitov <ast@plumgrid.com> Date: Tue, 4 Aug 2015 22:51:07 -0700 > IFLA_VXLAN_FLOWBASED is useless without IFLA_VXLAN_COLLECT_METADATA, > so combine them into single IFLA_VXLAN_COLLECT_METADATA flag. > 'flowbased' doesn't convey real meaning of the vxlan tunnel mode. > This mode can be used by routing, tc+bpf and ovs. > Only ovs is strictly flow based, so 'collect metadata' is a better > name for this tunnel mode. > > Signed-off-by: Alexei Starovoitov <ast@plumgrid.com> > --- > it's not too late to kill uapi IFLA_VXLAN_FLOWBASED, since it > was introduced two weeks ago. > Alternatively we could rename both into vxlan_accept_metadata > or something else, but imo collect_metadata is ok. Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi VxLAN experts, In user space, we are developing a CLI as the following: Interface tunnel 100 Mode vxlan Remote ip ipv4 19.1.1.1 Local ip ipv4 20.1.1.1 Vni 1-1000 <==== With Kernel 3.12.37, we can't support above configurations in kernel. (OR PLEASE Correct me if I am wrong) Noticing VxLAN supports has been actively worked on, hoping most Recent kernel allow functionality above is supported now. Pretty much what I want is that kernel will have about 1K interfaces (something like Tunnel100.1-tunnel100.1000 To be created and attached to 1K bridge domains on which each VNI is associated with given VNI to bridge-domain will be assigned using other CLIs) Thanks, Andrew ************* Email Confidentiality Notice ******************** The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you! -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 8/10/15 4:47 PM, Andrew Qu wrote: > > Pretty much what I want is that kernel will have about 1K interfaces (something like Tunnel100.1-tunnel100.1000 > To be created and attached to 1K bridge domains on which each VNI is associated with given > VNI to bridge-domain will be assigned using other CLIs) creating 1k vxlan devices is doable, but you probably want to take a look at recently added metadata mode of vxlan. Also sounds like for each vni you'd need a different multicast group? What fabric going to support that? > ************* Email Confidentiality Notice ******************** please avoid such banners. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Alexei, I support using mcast group for all VNIs in control plane/data plane. But in case there is no mcast routing enabled, I need to support P2P vxlan underlay, hence use of the configuration I showed. Thanks for the confirmation. By the way, any informational doc I can read to know about the metadata mode of vxlan? Andrew ======== please ignore my company added confidentiality notice on this thread ===================== -----Original Message----- From: Alexei Starovoitov [mailto:ast@plumgrid.com] Sent: Monday, August 10, 2015 10:37 PM To: Andrew Qu; David Miller Cc: tgraf@suug.ch; jesse@nicira.com; pshelar@nicira.com; netdev@vger.kernel.org Subject: Re: VxLAN support question On 8/10/15 4:47 PM, Andrew Qu wrote: > > Pretty much what I want is that kernel will have about 1K interfaces > (something like Tunnel100.1-tunnel100.1000 To be created and attached > to 1K bridge domains on which each VNI is associated with given VNI to > bridge-domain will be assigned using other CLIs) creating 1k vxlan devices is doable, but you probably want to take a look at recently added metadata mode of vxlan. Also sounds like for each vni you'd need a different multicast group? What fabric going to support that? > ************* Email Confidentiality Notice ******************** please avoid such banners. ************* Email Confidentiality Notice ******************** The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you! -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Alexei, I run into following issue: root@ODLserver:/home/andrew# ip li add vxlan0 type vxlan id 42 remote 171.1.1.1 local 170.1.1.1 dev eth1 ====> OK root@ODLserver:/home/andrew# ip li add vxlan1 type vxlan id 42 remote 172.1.1.1 local 170.1.1.1 dev eth2 ==> RTNETLINK answers: File exists Do you know why Linux kernel reject second CLI ? From user perspective, it is a perfect fine configuration because I want to create two P2P vxlan Tunnels to connect TWO VTEPs using same VNI. Thanks, Andrew root@ODLserver:/home/andrew# -----Original Message----- From: Alexei Starovoitov [mailto:ast@plumgrid.com] Sent: Monday, August 10, 2015 10:37 PM To: Andrew Qu; David Miller Cc: tgraf@suug.ch; jesse@nicira.com; pshelar@nicira.com; netdev@vger.kernel.org Subject: Re: VxLAN support question On 8/10/15 4:47 PM, Andrew Qu wrote: > > Pretty much what I want is that kernel will have about 1K interfaces > (something like Tunnel100.1-tunnel100.1000 To be created and attached > to 1K bridge domains on which each VNI is associated with given VNI to > bridge-domain will be assigned using other CLIs) creating 1k vxlan devices is doable, but you probably want to take a look at recently added metadata mode of vxlan. Also sounds like for each vni you'd need a different multicast group? What fabric going to support that? > ************* Email Confidentiality Notice ******************** please avoid such banners. ************* Email Confidentiality Notice ******************** The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you! -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c index e90f7a484e1c..b6731fad19ba 100644 --- a/drivers/net/vxlan.c +++ b/drivers/net/vxlan.c @@ -1141,7 +1141,7 @@ static void vxlan_rcv(struct vxlan_sock *vs, struct sk_buff *skb, union vxlan_addr *remote_ip; /* For flow based devices, map all packets to VNI 0 */ - if (vs->flags & VXLAN_F_FLOW_BASED) + if (vs->flags & VXLAN_F_COLLECT_METADATA) vni = 0; /* Is this VNI defined? */ @@ -1183,7 +1183,7 @@ static void vxlan_rcv(struct vxlan_sock *vs, struct sk_buff *skb, skb_reset_network_header(skb); /* In flow-based mode, GBP is carried in dst_metadata */ - if (!(vs->flags & VXLAN_F_FLOW_BASED)) + if (!(vs->flags & VXLAN_F_COLLECT_METADATA)) skb->mark = md->gbp; if (oip6) @@ -2129,7 +2129,7 @@ static netdev_tx_t vxlan_xmit(struct sk_buff *skb, struct net_device *dev) #endif } - if (vxlan->flags & VXLAN_F_FLOW_BASED && + if (vxlan->flags & VXLAN_F_COLLECT_METADATA && info && info->mode == IP_TUNNEL_INFO_TX) { vxlan_xmit_one(skb, dev, NULL, false); return NETDEV_TX_OK; @@ -2462,7 +2462,6 @@ static const struct nla_policy vxlan_policy[IFLA_VXLAN_MAX + 1] = { [IFLA_VXLAN_RSC] = { .type = NLA_U8 }, [IFLA_VXLAN_L2MISS] = { .type = NLA_U8 }, [IFLA_VXLAN_L3MISS] = { .type = NLA_U8 }, - [IFLA_VXLAN_FLOWBASED] = { .type = NLA_U8 }, [IFLA_VXLAN_COLLECT_METADATA] = { .type = NLA_U8 }, [IFLA_VXLAN_PORT] = { .type = NLA_U16 }, [IFLA_VXLAN_UDP_CSUM] = { .type = NLA_U8 }, @@ -2814,10 +2813,6 @@ static int vxlan_newlink(struct net *src_net, struct net_device *dev, if (data[IFLA_VXLAN_LIMIT]) conf.addrmax = nla_get_u32(data[IFLA_VXLAN_LIMIT]); - if (data[IFLA_VXLAN_FLOWBASED] && - nla_get_u8(data[IFLA_VXLAN_FLOWBASED])) - conf.flags |= VXLAN_F_FLOW_BASED; - if (data[IFLA_VXLAN_COLLECT_METADATA] && nla_get_u8(data[IFLA_VXLAN_COLLECT_METADATA])) conf.flags |= VXLAN_F_COLLECT_METADATA; @@ -2903,7 +2898,7 @@ static size_t vxlan_get_size(const struct net_device *dev) nla_total_size(sizeof(__u8)) + /* IFLA_VXLAN_RSC */ nla_total_size(sizeof(__u8)) + /* IFLA_VXLAN_L2MISS */ nla_total_size(sizeof(__u8)) + /* IFLA_VXLAN_L3MISS */ - nla_total_size(sizeof(__u8)) + /* IFLA_VXLAN_FLOWBASED */ + nla_total_size(sizeof(__u8)) + /* IFLA_VXLAN_COLLECT_METADATA */ nla_total_size(sizeof(__u32)) + /* IFLA_VXLAN_AGEING */ nla_total_size(sizeof(__u32)) + /* IFLA_VXLAN_LIMIT */ nla_total_size(sizeof(struct ifla_vxlan_port_range)) + @@ -2970,8 +2965,8 @@ static int vxlan_fill_info(struct sk_buff *skb, const struct net_device *dev) !!(vxlan->flags & VXLAN_F_L2MISS)) || nla_put_u8(skb, IFLA_VXLAN_L3MISS, !!(vxlan->flags & VXLAN_F_L3MISS)) || - nla_put_u8(skb, IFLA_VXLAN_FLOWBASED, - !!(vxlan->flags & VXLAN_F_FLOW_BASED)) || + nla_put_u8(skb, IFLA_VXLAN_COLLECT_METADATA, + !!(vxlan->flags & VXLAN_F_COLLECT_METADATA)) || nla_put_u32(skb, IFLA_VXLAN_AGEING, vxlan->cfg.age_interval) || nla_put_u32(skb, IFLA_VXLAN_LIMIT, vxlan->cfg.addrmax) || nla_put_be16(skb, IFLA_VXLAN_PORT, vxlan->cfg.dst_port) || diff --git a/include/net/vxlan.h b/include/net/vxlan.h index eb8d721cdb67..e4534f1b2d8c 100644 --- a/include/net/vxlan.h +++ b/include/net/vxlan.h @@ -181,7 +181,6 @@ struct vxlan_dev { #define VXLAN_F_GBP 0x800 #define VXLAN_F_REMCSUM_NOPARTIAL 0x1000 #define VXLAN_F_COLLECT_METADATA 0x2000 -#define VXLAN_F_FLOW_BASED 0x4000 /* Flags that are used in the receive path. These flags must match in * order for a socket to be shareable @@ -190,8 +189,7 @@ struct vxlan_dev { VXLAN_F_UDP_ZERO_CSUM6_RX | \ VXLAN_F_REMCSUM_RX | \ VXLAN_F_REMCSUM_NOPARTIAL | \ - VXLAN_F_COLLECT_METADATA | \ - VXLAN_F_FLOW_BASED) + VXLAN_F_COLLECT_METADATA) struct net_device *vxlan_dev_create(struct net *net, const char *name, u8 name_assign_type, struct vxlan_config *conf); diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h index ea047480a1f0..f24ec99a2262 100644 --- a/include/uapi/linux/if_link.h +++ b/include/uapi/linux/if_link.h @@ -382,7 +382,6 @@ enum { IFLA_VXLAN_REMCSUM_RX, IFLA_VXLAN_GBP, IFLA_VXLAN_REMCSUM_NOPARTIAL, - IFLA_VXLAN_FLOWBASED, IFLA_VXLAN_COLLECT_METADATA, __IFLA_VXLAN_MAX }; diff --git a/net/openvswitch/vport-vxlan.c b/net/openvswitch/vport-vxlan.c index 547173336cd3..c6e937e36f8b 100644 --- a/net/openvswitch/vport-vxlan.c +++ b/net/openvswitch/vport-vxlan.c @@ -90,7 +90,7 @@ static struct vport *vxlan_tnl_create(const struct vport_parms *parms) int err; struct vxlan_config conf = { .no_share = true, - .flags = VXLAN_F_FLOW_BASED | VXLAN_F_COLLECT_METADATA, + .flags = VXLAN_F_COLLECT_METADATA, }; if (!options) {
IFLA_VXLAN_FLOWBASED is useless without IFLA_VXLAN_COLLECT_METADATA, so combine them into single IFLA_VXLAN_COLLECT_METADATA flag. 'flowbased' doesn't convey real meaning of the vxlan tunnel mode. This mode can be used by routing, tc+bpf and ovs. Only ovs is strictly flow based, so 'collect metadata' is a better name for this tunnel mode. Signed-off-by: Alexei Starovoitov <ast@plumgrid.com> --- it's not too late to kill uapi IFLA_VXLAN_FLOWBASED, since it was introduced two weeks ago. Alternatively we could rename both into vxlan_accept_metadata or something else, but imo collect_metadata is ok. drivers/net/vxlan.c | 17 ++++++----------- include/net/vxlan.h | 4 +--- include/uapi/linux/if_link.h | 1 - net/openvswitch/vport-vxlan.c | 2 +- 4 files changed, 8 insertions(+), 16 deletions(-)