Re: [ovs-dev] [PATCH] netdev: Retry getting interfaces on inconsistent dumps from kernel

and since it's unlikely that we hit the race condition 3 times in > a row. Still, if this happened, this patch is not changing the > current behavior. > > [0] > https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=c1f86a33ca32e26a9d6e29fc961e5ecb5e2e5eb4 > > Signed-off-by:

Re: [ovs-dev] [PATCH] dpif: Ensure ERSPAN GRE support

On Fri, 1 Jun 2018 11:23:12 -0700, William Tu wrote: > Looking at the dpif_netlink_rtnl_probe_oot_tunnels(), since now we > added ERSPAN feature, instead of probing geneve module, > we should probe ip_gre module with a nlattr of ERSPAN (ex: HWID). > If it does not return -ENOSUPPORT, then use the

Re: [ovs-dev] [PATCH] dpif: Ensure ERSPAN GRE support

the value back. As for the patch, Nacked-by: Jiri Benc Jiri ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] datapath: compat: Fix ndo_size in RHEL 7.5 backport

On Thu, 17 May 2018 12:39:51 -0700, Yi-Hung Wei wrote: > If 'ndo_size' is not set in 'struct net_device_ops', RHEL kernel will not > make use of functions in 'struct net_device_ops_extended'. > > Fixes: 39ca338374ab ("datapath: compat: Fix build on RHEL 7.5") > R

Re: [ovs-dev] [PATCH v2] datapath: compat: Fix build on RHEL 7.5

On Fri, 11 May 2018 10:32:12 -0700, Yi-Hung Wei wrote: > --- a/datapath/linux/compat/geneve.c > +++ b/datapath/linux/compat/geneve.c > @@ -1271,7 +1271,11 @@ static const struct net_device_ops geneve_netdev_ops = > { > .ndo_stop = geneve_stop, > .ndo_start_xmit =

Re: [ovs-dev] [PATCH] odp-util: Fix ofproto/trace with odp flow

On Tue, 13 Mar 2018 09:36:23 -0700, Darrell Ball wrote: > [Darrell] There was no suggestion otherwise in general. We were discussing > for one the difference b/w kernel and userspace DP for handling packet type > aware support. Specifically, the difference is here is as fundamental as it > gets -

Re: [ovs-dev] [PATCH] odp-util: Fix ofproto/trace with odp flow

Darell, please fix your email client configuration to conform to RFC 3676 (https://tools.ietf.org/html/rfc3676#section-4.5). Your replies are unreadable. In particular, the text you're replying to must be quoted by ">" character, clearly separating your reply from the original email. Also, wrap

Re: [ovs-dev] [RFC] dpif-netlink: don't allocate per port netlink sockets

On Tue, 23 Jan 2018 09:50:00 -0800, Ben Pfaff wrote: > Per-port sockets help OVS to improve fairness, so that a single busy > port can't monopolize all slow-path resources. We can't just throw that > away. If there's a problem with too many netlink sockets, let's come up > with a solution, but

Re: [ovs-dev] [PATCH net v3] openvswitch: Fix pop_vlan action for double tagged frames

37 ("openvswitch: add processing of L3 packets") > Signed-off-by: Eric Garver <e...@erig.me> Thanks! Reviewed-by: Jiri Benc <jb...@redhat.com> ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net v2] openvswitch: Fix pop_vlan action for double tagged frames

On Wed, 20 Dec 2017 10:39:32 -0500, Eric Garver wrote: > + if (is_flow_key_valid(key) && key->eth.vlan.tci && key->eth.cvlan.tci) Maybe (key->eth.vlan.tci & htons(VLAN_TAG_PRESENT)) for consistency with the rest of the code? But it's just nitpicking. The real problem here is when a double

Re: [ovs-dev] [PATCH net] openvswitch: Fix pop_vlan action for double tagged frames

On Tue, 19 Dec 2017 13:57:53 -0500, Eric Garver wrote: > --- a/net/openvswitch/flow.c > +++ b/net/openvswitch/flow.c > @@ -559,8 +559,9 @@ static int parse_nsh(struct sk_buff *skb, struct > sw_flow_key *key) > * of a correct length, otherwise the same as skb->network_header. > * For

Re: [ovs-dev] [PATCH v2 1/8] netlink: provide network namespace id from a msg.

On Mon, 4 Dec 2017 11:44:19 -0200, Flavio Leitner wrote: > It is only positive numbers if you review the kernel sources today, > but the API is exposing signed 32bit, so not sure what can happen > in the future if the kernel decides to expand the range. I think you can assume that it will always

Re: [ovs-dev] [PATCH net-next v15] openvswitch: enable NSH support

On Sat, 4 Nov 2017 07:29:46 -0700, Pravin Shelar wrote: > > +int nsh_push(struct sk_buff *skb, const struct nshhdr *pushed_nh) > > +{ > > + struct nshhdr *nh; > > + size_t length = nsh_hdr_len(pushed_nh); > > + u8 next_proto; > > + > > + if (skb->mac_len) { > > +

Re: [ovs-dev] [PATCH net-next v15] openvswitch: enable NSH support

On Wed, 1 Nov 2017 12:03:01 +0800, Yi Yang wrote: > v14->v15 > - Check size in nsh_hdr_from_nlattr > - Fixed four small issues pointed out By Jiri and Eric Acked-by: Jiri Benc <jb...@redhat.com> ___ dev mailing list d...@ope

Re: [ovs-dev] [PATCH net-next v14] openvswitch: enable NSH support

On Mon, 30 Oct 2017 09:29:34 +0800, Yi Yang wrote: > +static int set_nsh(struct sk_buff *skb, struct sw_flow_key *flow_key, > +const struct nlattr *a) > +{ > + struct nshhdr *nh; > + size_t length; > + int err; > + u8 flags; > + u8 ttl; > + int i; > + > +

Re: [ovs-dev] [PATCH net-next v14] openvswitch: enable NSH support

On Tue, 31 Oct 2017 15:57:41 -0400, Eric Garver wrote: > On Mon, Oct 30, 2017 at 09:29:34AM +0800, Yi Yang wrote: > > + if (WARN_ON(is_push_nsh && is_mask)) > > + return -EINVAL; > > OVS_NLERR() is probably more appropriate. No, not here. If this happens, it's a bug in the kernel and

Re: [ovs-dev] [PATCH net-next v12] openvswitch: enable NSH support

On Fri, 20 Oct 2017 05:53:12 +0800, Yang, Yi wrote: > For push_nsh, my typical use scinario is push_nsh then set then output > to vxlangpe port. Okay. Jiri ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v12] openvswitch: enable NSH support

On Thu, 19 Oct 2017 21:12:15 +0800, Yang, Yi wrote: > flow_key in set_nsh is got from netlink message which is set by > commit_nsh in user space, here is code. Isn't this the 'key' local variable that you're talking about, while I'm referring to the 'flow_key' parameter? Jiri

Re: [ovs-dev] [PATCH net-next v12] openvswitch: enable NSH support

On Thu, 19 Oct 2017 19:40:53 +0800, Yang, Yi wrote: > Actually mdtype can't be set, only push_nsh can set mdtype, so set_nsh > won't have mdtype flow key, we can't get it from flow_key in set_nsh, > only ttl, flags and path_hdr can be set in set_nsh as you can see in code. > I understand your

Re: [ovs-dev] [PATCH net-next v12] openvswitch: enable NSH support

On Mon, 16 Oct 2017 21:53:29 +0800, Yi Yang wrote: > +static int set_nsh(struct sk_buff *skb, struct sw_flow_key *flow_key, > +const struct nlattr *a) > +{ > + struct nshhdr *nh; > + size_t length; > + int err; > + u8 flags; > + u8 ttl; > + int i; > + > +

Re: [ovs-dev] [PATCH net-next v11] openvswitch: enable NSH support

On Fri, 29 Sep 2017 15:03:30 +0800, Yi Yang wrote: > --- a/include/net/nsh.h > +++ b/include/net/nsh.h > @@ -304,4 +304,7 @@ static inline void nsh_set_flags_ttl_len(struct nshhdr > *nsh, u8 flags, > NSH_FLAGS_MASK | NSH_TTL_MASK | NSH_LEN_MASK); > } > > +int

Re: [ovs-dev] [PATCH net-next v10] openvswitch: enable NSH support

On Tue, 26 Sep 2017 21:52:41 +0800, Yang, Yi wrote: > > + return ((ret != 0) ? false : true); > > But I don't think this is a problematic line from my understanding, Why not: return ((ret != 0 == true) ? false : true) == true; ? Sigh. This is equal to: return !ret; which

Re: [ovs-dev] [PATCH net-next v10] openvswitch: enable NSH support

On Tue, 26 Sep 2017 12:47:16 +0800, Yi Yang wrote: > + return ((ret != 0) ? false : true); I'm not going to review this version but this caught my eye - I pointed out this silly construct in my review of v9. I can understand that working late in the night and rewriting the code back and

Re: [ovs-dev] [PATCH net-next v10] openvswitch: enable NSH support

On Tue, 26 Sep 2017 12:47:16 +0800, Yi Yang wrote: > v9->v10 > - Change struct ovs_key_nsh to >struct ovs_nsh_key_base base; >__be32 context[NSH_MD1_CONTEXT_SIZE]; > - Fix new comments for v9 NAK, we haven't finished the discussion for v9 yet. It's not appropriate to send a new

Re: [ovs-dev] [PATCH net-next v9] openvswitch: enable NSH support

On Tue, 26 Sep 2017 12:55:39 +0800, Yang, Yi wrote: > After push_nsh, the packet won't be recirculated to flow pipeline, so > key->eth.type must be set explicitly here, but for pop_nsh, the packet > will be recirculated to flow pipeline, it will be reparsed, so > key->eth.type will be set in

Re: [ovs-dev] [PATCH net-next v9] openvswitch: enable NSH support

On Mon, 25 Sep 2017 22:16:09 +0800, Yi Yang wrote: > + skb->protocol = htons(ETH_P_NSH); > + skb_reset_mac_header(skb); > + skb_reset_mac_len(skb); > + skb_reset_network_header(skb); The last two lines are swapped. Network header needs to be reset before mac_len. > + > +

Re: [ovs-dev] [PATCH net-next v9] openvswitch: enable NSH support

On Thu, 14 Sep 2017 16:37:59 +0800, Yi Yang wrote: > OVS master and 2.8 branch has merged NSH userspace > patch series, this patch is to enable NSH support > in kernel data path in order that OVS can support > NSH in compat mode by porting this. http://vger.kernel.org/~davem/net-next.html

Re: [ovs-dev] [PATCH net-next v7] openvswitch: enable NSH support

On Mon, 4 Sep 2017 14:45:50 +, Jan Scheurich wrote: > So what is the correct layout for MASKED_SET action with nested fields? > 1. All nested values, followed by all nested masks, or > 2. For each nested field value followed by mask? > > I guess alternative 1, but just to be sure. It's 2.

Re: [ovs-dev] [PATCH net-next v7] openvswitch: enable NSH support

On Tue, 5 Sep 2017 14:37:05 +0800, Yang, Yi wrote: > I checked source code but can't find where we can prepopulate it and how > we can deliver the prepopulated header to push_nsh, can you expand it in > order that I can know how to do this in code level? I already said that it's not implemented

Re: [ovs-dev] [PATCH net-next v7] openvswitch: enable NSH support

On Tue, 5 Sep 2017 13:51:45 +0800, Yang, Yi wrote: > But if we follow your way, how does nla_for_each_nested handle such > pattern? > > attribute1 > attribute1_mask > attribute2 > attribute2_mask > attribute3 > attribute3_mask Uh? That will just work. Note that nla len contains the size of the

Re: [ovs-dev] [PATCH net-next v7] openvswitch: enable NSH support

On Mon, 4 Sep 2017 14:07:45 +, Jan Scheurich wrote: > Then perhaps I misunderstood your comment. I thought you didn't like that the > SET_MASKED action wrapped OVS_KEY_ATTR_NSH which in itself was nested. > I was aiming to avoid this by lifting the two components of the NSH header >

Re: [ovs-dev] [PATCH net-next v7] openvswitch: enable NSH support

On Mon, 4 Sep 2017 12:57:15 +, Jan Scheurich wrote: > So is what you are suggesting the following? > > For matching: > OVS_KEY_ATTR_NSH_BASE_HEADER mandatory > OVS_KEY_ATTR_NSH_MD1_CONTEXT optional, in case MDTYPE == MD1 This needs to be: OVS_KEY_ATTR_NSH

Re: [ovs-dev] [PATCH net-next v7] openvswitch: enable NSH support

On Wed, 30 Aug 2017 20:39:12 +0800, Yi Yang wrote: > +enum ovs_nsh_key_attr { > + OVS_NSH_KEY_ATTR_BASE, /* struct ovs_nsh_key_base. */ > + OVS_NSH_KEY_ATTR_MD1, /* struct ovs_nsh_key_md1. */ > + OVS_NSH_KEY_ATTR_MD2, /* variable-length octets for MD type 2. */ > +

Re: [ovs-dev] [PATCH net-next v7] openvswitch: enable NSH support

On Mon, 4 Sep 2017 20:09:07 +0800, Yang, Yi wrote: > So we must do many changes if we want to break this assumption. We may do as many changes as we want to. This is uAPI we're talking about and we need to get it right since the beginning. Sure, it may mean that some user space programs need some

Re: [ovs-dev] [PATCH net-next v7] openvswitch: enable NSH support

On Mon, 4 Sep 2017 16:00:05 +0800, Yang, Yi wrote: > I think we have had similiar discussion about this, the issue is we have > no way to handle both MD type 1 and MD type 2 by using a common flow key > struct. > > So we have to do so, there is miniflow to handle such issue in > userspace, but

Re: [ovs-dev] [PATCH net-next v7] openvswitch: enable NSH support

On Wed, 30 Aug 2017 20:39:12 +0800, Yi Yang wrote: > --- a/net/nsh/nsh.c > +++ b/net/nsh/nsh.c > @@ -14,6 +14,47 @@ > #include > #include > > +int skb_push_nsh(struct sk_buff *skb, const struct nshhdr *nsh_src, bool > is_eth) > +{ > + struct nshhdr *nsh; > + size_t length =

Re: [ovs-dev] [PATCH] NEWS: Mark NSH support as experimental in 2.8.

On Tue, 29 Aug 2017 10:50:11 -0700, Ben Pfaff wrote: > This feature landed late in 2.8 and the NSH wire protocol itself is not > completely stable. Acked-by: Jiri Benc <jb...@redhat.com> ___ dev mailing list d...@openvswit

Re: [ovs-dev] [PATCH net-next v6 2/3] net: gso: Add GSO support for NSH

On Fri, 25 Aug 2017 18:25:14 +0200, Jiri Benc wrote: > While looking at this, I realized that GSO for VXLAN-GPE is broken, > too. Let me fix it by implementing what I described above which will > make your patch much easier. Okay, it's not really broken and we don't need that complexity.

Re: [ovs-dev] [PATCH net-next v6 2/3] net: gso: Add GSO support for NSH

On Fri, 25 Aug 2017 22:20:04 +0800, Yi Yang wrote: > --- a/include/linux/skbuff.h > +++ b/include/linux/skbuff.h > @@ -766,7 +766,7 @@ struct sk_buff { > __u8ndisc_nodetype:2; > #endif > __u8ipvs_property:1; > - __u8

Re: [ovs-dev] [PATCH net-next v6 1/3] net: add NSH header structures and helpers

On Fri, 25 Aug 2017 22:20:03 +0800, Yi Yang wrote: > --- a/include/uapi/linux/if_ether.h > +++ b/include/uapi/linux/if_ether.h > @@ -138,6 +138,7 @@ > #define ETH_P_IEEE802154 0x00F6 /* IEEE802.15.4 frame > */ > #define ETH_P_CAIF 0x00F7 /* ST-Ericsson CAIF

Re: [ovs-dev] [PATCH net-next v4] openvswitch: enable NSH support

On Tue, 22 Aug 2017 17:38:26 +0800, Yang, Yi wrote: > I checked GSO support code, we have two cases to handle, one case is to > output NSH packet to VxLAN-gpe port, the other case is to output NSH packet > to Ethernet port (tap, veth, vhost, physical eth, etc.), I don't think > it is a good way to

Re: [ovs-dev] [PATCH net-next v4] openvswitch: enable NSH support

On Mon, 21 Aug 2017 10:10:38 +, Jan Scheurich wrote: > If I understand correctly, this is a default definition that can be > overridden by drivers so that we still cannot rely on the Ethernet > payload always being 32-bit-aligned. Not by drivers, by architectures. Only architectures that can

Re: [ovs-dev] [PATCH net-next v4] openvswitch: enable NSH support

On Mon, 21 Aug 2017 17:15:42 +0800, Yang, Yi wrote: > The issue is it is used union in > > struct nsh_hdr { > ovs_be16 ver_flags_ttl_len; > uint8_t md_type; > uint8_t next_proto; > ovs_16aligned_be32 path_hdr; > union { > struct nsh_md1_ctx md1; > struct

Re: [ovs-dev] [PATCH net-next v4] openvswitch: enable NSH support

On Fri, 18 Aug 2017 15:26:01 +0200, Jiri Benc wrote: > Out of time for today, will continue the review next week. Again, feel > free to send a new version meanwhile or wait for the rest of the > review, whatever works better for you. One more thing: before you send a new version

Re: [ovs-dev] [PATCH net-next v4] openvswitch: enable NSH support

On Fri, 18 Aug 2017 15:24:31 +0800, Yi Yang wrote: > +struct nsh_md2_tlv { > + __be16 md_class; > + u8 type; > + u8 length; > + /* Followed by variable-length data. */ > +}; What was wrong with the u8[] field that was present at the end of the struct in the previous version of the

Re: [ovs-dev] [PATCH v3] openvswitch: enable NSH support

On Wed, 16 Aug 2017 17:31:30 +0800, Yang, Yi wrote: > On Wed, Aug 16, 2017 at 11:19:21AM +0200, Jiri Benc wrote: > > > --- a/include/uapi/linux/openvswitch.h > > > +++ b/include/uapi/linux/openvswitch.h > > [...] > > > +#define NSH_MD1_CONTEXT_SIZE 4 > &

Re: [ovs-dev] [PATCH net-next v2] openvswitch: enable NSH support

On Mon, 14 Aug 2017 10:35:42 +, Jan Scheurich wrote: > Is it worth to speculate on how a hypothetical future NSH version > (with a different Version value in the Base header) might look like? Absolutely. This is uAPI we're talking about and once merged, it's set in stone. Whatever we come up

Re: [ovs-dev] [PATCH net-next v2] openvswitch: enable NSH support

On Sun, 13 Aug 2017 21:13:57 +, Jan Scheurich wrote: > Jiri, I am not too familiar with conventions on the OVS netlink > interface regarding the handling of variable length fields. What is > the benefit of structuring the push_nsh action into > > OVS_ACTION_ATTR_PUSH_NSH > +--

Re: [ovs-dev] [PATCH net-next v2] openvswitch: enable NSH support

On Fri, 11 Aug 2017 10:09:36 +, Jan Scheurich wrote: > Unless someone can explain to me why the datapath should understand the > internal structure/format of metadata in push_nsh, I would strongly > vote to keep the metadata as variable length octet sequence in the > non-structured

Re: [ovs-dev] [PATCH net-next v2] openvswitch: enable NSH support

On Fri, 11 Aug 2017 09:24:25 +, 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

Re: [ovs-dev] [PATCH net-next v2] openvswitch: enable NSH support

On Fri, 11 Aug 2017 16:47:23 +0800, Yang, Yi wrote: > is "__be32 context[4]" ok? Yes, that looks better. > So define three new netlink attributes > > OVS_ACTION_ATTR_NSH_BASE_HEADER > OVS_ACTION_ATTR_NSH_MD1_DATA > OVS_ACTION_ATTR_NSH_MD2_DATA > > OVS_ACTION_ATTR_PUSH_NSH is nested netlink

Re: [ovs-dev] [PATCH net-next v2] openvswitch: enable NSH support

On Thu, 10 Aug 2017 21:21:15 +0800, Yi Yang wrote: > OVS master and 2.8 branch has merged NSH userspace > patch series, this patch is to enable NSH support > in kernel data path in order that OVS can support > NSH in 2.8 release in compat mode by porting this. Please include changelog when

Re: [ovs-dev] [PATCH net-next] openvswitch: add NSH support

On Tue, 8 Aug 2017 12:59:40 +0800, Yi Yang wrote: > +struct ovs_key_nsh { > + __u8 flags; > + __u8 mdtype; > + __u8 np; > + __u8 pad; > + __be32 path_hdr; > + __be32 c[4]; "c" is a very poor name. Please rename it to something that expresses what this field contains.

Re: [ovs-dev] [PATCH net-next v3 1/6] vxlan: refactor verification and application of configuration

This patchset looks good overall (would send my Acked-by for most of this but I'm late). On Mon, 19 Jun 2017 10:03:55 +0200, Matthias Schiffer wrote: > Log messages in these > functions are removed, as it is generally unexpected to find error output > for netlink requests in the kernel log.

Re: [ovs-dev] [PATCH v4 2/7] userspace: Support for push_eth and pop_eth actions

On Thu, 4 May 2017 12:53:25 -0700, Joe Stringer wrote: > On 4 May 2017 at 12:51, Joe Stringer wrote: > > Really? Previously the OVS usage of netlink always validated that > > netlink attributes are exactly as long as expected and that there's no > > trailing data. > > With a glance

Re: [ovs-dev] [PATCH v4 2/7] userspace: Support for push_eth and pop_eth actions

On Thu, 4 May 2017 10:02:22 +, Zoltán Balogh wrote: > I'm afraid the kernel would not accept that OVS_ACTION_ATTR_PUSH_ETH > action in this case. > > Jiri, could you confirm, please? It would accept it and it would ignore the eth_type field. The kernel does not verify whether netlink

Re: [ovs-dev] Sync on PTAP, EXT-382 and NSH

On Wed, 18 Jan 2017 09:53:18 +, Jan Scheurich wrote: > Please be invited to the next sync meeting. Sorry, won't make the meeting today. Too busy with DevConf.cz preparations. > Actions Points: > AP-1 (Jarno): Coordinate review of Yi's backported net-next patches > AP-2 (Jiri) Check the

Re: [ovs-dev] [RFC PATCH] datapath: allow tunnels to be created with rtnetlink

On Tue, 10 Jan 2017 15:44:07 +0100, Jiri Benc wrote: > create an ovs_geneve interface using rtnetlink This can be done just once. The pseudocode at startup thus would be: create an ovs_geneve interface using rtnetlink if successful { delete the created interface set out_of_t

Re: [ovs-dev] Sync on PTAP, EXT-382 and NSH

On Mon, 9 Jan 2017 11:15:22 +, Yang, Yi Y wrote: > We need to let users have one NSH version available before your > proposal is implemented. I support your proposal, but I have no way > to do anything helpful before your implementation for generic > encap/decap and packet_type are available.

Re: [ovs-dev] Sync on PTAP, EXT-382 and NSH

Hi Jan, On Sun, 18 Dec 2016 14:44:03 +, Jan Scheurich wrote: > I would like to call for a final sync meeting before the Christmas break. you managed to hit almost the only slot in this week when I have a conflict with another meeting. I'm not available on Tuesday starting at the time you

Re: [ovs-dev] [PATCH net-next 17/27] OVS: remove assumptions about VLAN_TAG_PRESENT bit

On Tue, 13 Dec 2016 01:12:38 +0100 (CET), Michał Mirosław wrote: > @@ -850,20 +848,11 @@ static int validate_vlan_from_nlattrs(const struct > sw_flow_match *match, > return -EINVAL; > } > > - if (a[OVS_KEY_ATTR_VLAN]) > - tci =

Re: [ovs-dev] [RFC PATCH] datapath: allow tunnels to be created with rtnetlink

On Thu, 8 Dec 2016 22:49:56 -0800, Pravin Shelar wrote: > OVS out of tree kernel module is using compat tunnel code upto kernel > 4.5 kernel even thought LWT is available in these kernels. This is due > to missing features on these kernel which are backported to OVS > module. In future we could

Re: [ovs-dev] [PATCH net-next] openvswitch: fix VxLAN-gpe port can't be created in ovs compat mode

On Thu, 8 Dec 2016 18:57:51 +0800, Yang, Yi wrote: > So ovs out of tree modules need to adapt to upstream kernel, any > kernel-related changes must be accepted by Linux kernel at first. I'm perfectly aware of that and I'm saying that your patch is unacceptable for upstream kernel. This is a long

Re: [ovs-dev] [RFC PATCH] datapath: allow tunnels to be created with rtnetlink

On Wed, 7 Dec 2016 16:35:59 -0800, Pravin Shelar wrote: > In compat mode, OVS tunnel devices are not used in same way as LWT, > since OVS do support kernel version that does not have core LWT > support. Therefore we have to use legacy vport APIs to create these > ports. I see. Yes, that's

Re: [ovs-dev] [PATCH net-next] openvswitch: fix VxLAN-gpe port can't be created in ovs compat mode

On Thu, 8 Dec 2016 16:20:10 +0800, Yi Yang wrote: > In ovs compat mode, ovs won't use LWT in current kernel, this is to > make sure ovs can work on the old kernels, Linux kernel v4.7 includes > VxLAN-gpe support but many Linux distributions' kernels are odler than > v4.7, this fix will ensure

Re: [ovs-dev] [RFC PATCH] datapath: allow tunnels to be created with rtnetlink

On Wed, 7 Dec 2016 09:03:39 +0800, Yang, Yi wrote: > But ovs userspace use genetlink to create vxlan tunnel port when we > build ovs to use its own compat modules, this is case 3 Pravin, how > do you think we can handle this? Where's the problem? I don't see any. > Now the dilemma is we can't

Re: [ovs-dev] [RFC PATCH] datapath: allow tunnels to be created with rtnetlink

cases Pravin > mentioned. There's no reason to add this to the genetlink interface when we're going to switch to rtnetlink for tunnel configuration. NACKed-by: Jiri Benc <jb...@redhat.com> ___ dev mailing list d...@openvswitch.org https://mail.op

Re: [ovs-dev] Packet type-aware pipeline, L3 tunneling, EXT-382 and NSH: Minutes call 2016-11-29

On Wed, 30 Nov 2016 22:52:38 +, Jan Scheurich wrote: > The corresponding section in the document is already updated with the > results of the discussion. So please have look. There's also a short > summary of the main results at the end of the mail. Thanks for writing that down. I see several

Re: [ovs-dev] [PATCH v12 rebased 1/3] userspace: add support for pop_eth and push_eth actions

On Mon, 28 Nov 2016 16:56:27 -0800, Ben Pfaff wrote: > I know that this isn't intended to be applied yet, according to the > cover letter, but it doesn't build: > > ../lib/odp-util.c:5504:15: error: no member named 'base_layer' in 'struct > flow' > ../lib/odp-util.c:5504:40: error: no

[ovs-dev] [PATCH net-next v13 4/8] openvswitch: support MPLS push and pop for L3 packets

Update Ethernet header only if there is one. Signed-off-by: Jiri Benc <jb...@redhat.com> Acked-by: Pravin B Shelar <pshe...@ovn.org> --- net/openvswitch/actions.c | 18 +++--- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/net/openvswitch/actions.c b/net

[ovs-dev] [PATCH net-next v13 3/8] openvswitch: pass mac_proto to ovs_vport_send

packet. For example, ARPHRD_NONE tunnels that encapsulate Ethernet should get at least the Ethernet header. Signed-off-by: Jiri Benc <jb...@redhat.com> Acked-by: Pravin B Shelar <pshe...@ovn.org> --- net/openvswitch/actions.c | 29 + net/openvswitch/vport.c

[ovs-dev] [PATCH net-next v13 1/8] openvswitch: use hard_header_len instead of hardcoded ETH_HLEN

packet going to L3 interface. Signed-off-by: Jiri Benc <jb...@redhat.com> Acked-by: Pravin B Shelar <pshe...@ovn.org> --- net/openvswitch/actions.c | 3 ++- net/openvswitch/vport.c | 10 ++ 2 files changed, 8 insertions(+), 5 deletions(-) diff --git a/net/openvswitch/act

Re: [ovs-dev] [PATCH net-next v12 7/9] openvswitch: add Ethernet push and pop actions

On Thu, 20 Oct 2016 21:22:21 -0700, Pravin Shelar wrote: > The eth pop substracts ETH_HLEN but here the length is set. I think it > should be consistent with respect to eth-pop. Agreed. Will use skb_reset_mac_len in both, that better reflects what's going on. Thanks, Jiri

Re: [ovs-dev] [PATCH net-next v12 5/9] openvswitch: add processing of L3 packets

On Thu, 20 Oct 2016 21:19:14 -0700, Pravin Shelar wrote: > On Mon, Oct 17, 2016 at 6:02 AM, Jiri Benc <jb...@redhat.com> wrote: > > @@ -609,8 +597,10 @@ static int ovs_packet_cmd_execute(struct sk_buff *skb, > > struct genl_info *info) > > > > err = o

[ovs-dev] [PATCH v12 rebased 1/3] userspace: add support for pop_eth and push_eth actions

.hor...@netronome.com> Signed-off-by: Jiri Benc <jb...@redhat.com> --- v12 [Simon Horman] * Rebase * Provide commit_ether_action() v11 [Simon Horman] * Omit type field from push_eth action, it is not needed as the type of the packet is already known v10 [Simon Horman] * No Change v9 [Si

[ovs-dev] [PATCH v12 rebased 3/3] userspace: add non-tap (l3) support to GRE vports

inner-packets. Signed-off-by: Simon Horman <simon.hor...@netronome.com> Signed-off-by: Jiri Benc <jb...@redhat.com> --- v12 * Rebase v11 * Update for new kernel implementation that uses ARPHRD_NONE devices * Omit match_base_layer from struct tun_port_in, it is not necessary

[ovs-dev] [PATCH v12 rebased 2/3] userspace: add layer 3 flow and switching support

ja...@cisco.com> Signed-off-by: Simon Horman <simon.hor...@netronome.com> Signed-off-by: Jiri Benc <jb...@redhat.com> --- v12+ * Correct ATTR_ETHERTYPE/ETHERNET logic in odp_key_to_pkt_metadata() v12 [Simon Horman] * No change v11 [Simon Horman] * Fold in previously separate pat

[ovs-dev] [PATCH v12 rebased 0/3] userspace: Support for layer 3 encapsulated packets

This is a rebase of Simon's submission from July on top of the current master. It is not intended to be applied yet but to help testing of the kernel part. The rebase was straightforward, the differences are: * Accomodated changes made by aff49b8c66be ("meta-flow: Clean up masking with

Re: [ovs-dev] [PATCH net-next v12 0/9] openvswitch: support for layer 3 encapsulated packets

On Tue, 18 Oct 2016 22:11:21 -0700, Pravin Shelar wrote: > I have not finished the review yet, but most of patches looks good to > me. Can you send userspace patches against latest master so that I can > try the patches with tunnel setup? Will do in a few minutes. Thanks for the review, Jiri

Re: [ovs-dev] [PATCH net-next v12 9/9] openvswitch: use ipgre tunnel rather than gretap tunnel

On Tue, 18 Oct 2016 22:14:06 -0700, Pravin Shelar wrote: > This is OVS tunnel compatibility code. We are not suppose to add new > features to compat code. Just provide a way to configure such device > over rtnl. Makes sense. Please consider this a test-only patch for now. I won't include it in

Re: [ovs-dev] [PATCH net-next v12 5/9] openvswitch: add processing of L3 packets

On Tue, 18 Oct 2016 22:13:45 -0700, Pravin Shelar wrote: > On Mon, Oct 17, 2016 at 6:02 AM, Jiri Benc <jb...@redhat.com> wrote: > > - skb_reset_network_header(skb); > > + skb->protocol = parse_ethertype(skb); > > I am not sure about changing skb

[ovs-dev] [PATCH net-next v2 2/2] openvswitch: remove unnecessary EXPORT_SYMBOLs

Some symbols exported to other modules are really used only by openvswitch.ko. Remove the exports. Tested by loading all 4 openvswitch modules, nothing breaks. Signed-off-by: Jiri Benc <jb...@redhat.com> --- v2: ovs_vport_deferred_free is completely removed by the first patch --

[ovs-dev] [PATCH net-next v2 0/2] openvswitch: remove unused code

Removed unused functions and unnecessary EXPORT_SYMBOLs from openvswitch. Jiri Benc (2): openvswitch: remove unused functions openvswitch: remove unnecessary EXPORT_SYMBOLs net/openvswitch/datapath.c | 2 -- net/openvswitch/vport-netdev.c | 1 - net/openvswitch/vport.c| 17

[ovs-dev] [PATCH net-next v2 1/2] openvswitch: remove unused functions

ovs_vport_deferred_free is not used anywhere. It's the only caller of free_vport_rcu thus this one can be removed, too. Signed-off-by: Jiri Benc <jb...@redhat.com> --- new in v2 --- net/openvswitch/vport.c | 16 net/openvswitch/vport.h | 1 - 2 files changed, 17 del

Re: [ovs-dev] [PATCH net-next] openvswitch: remove unnecessary EXPORT_SYMBOLs

On Tue, 18 Oct 2016 12:48:33 -0700, Pravin Shelar wrote: > ovs_vport_deferred_free() is not used anywhere. can you remove it? Good point. Will do. Jiri ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH net-next] openvswitch: remove unnecessary EXPORT_SYMBOLs

Many symbols exported to other modules are really used only by openvswitch.ko. Remove the exports. Tested by loading all 4 openvswitch modules, nothing breaks. Signed-off-by: Jiri Benc <jb...@redhat.com> --- net/openvswitch/datapath.c | 2 -- net/openvswitch/vport-netdev.c | 1

[ovs-dev] [PATCH net-next v12 7/9] openvswitch: add Ethernet push and pop actions

<loja...@cisco.com> Signed-off-by: Simon Horman <simon.hor...@netronome.com> Signed-off-by: Jiri Benc <jb...@redhat.com> --- include/uapi/linux/openvswitch.h | 15 net/openvswitch/actions.c| 49 net/openvswitch/flo

[ovs-dev] [PATCH net-next v12 8/9] openvswitch: allow L3 netdev ports

Allow ARPHRD_NONE interfaces to be added to ovs bridge. Based on previous versions by Lorand Jakab and Simon Horman. Signed-off-by: Lorand Jakab <loja...@cisco.com> Signed-off-by: Simon Horman <simon.hor...@netronome.com> Signed-off-by: Jiri Benc <jb...@redhat.com> --- net

[ovs-dev] [PATCH net-next v12 9/9] openvswitch: use ipgre tunnel rather than gretap tunnel

From: Simon Horman <simon.hor...@netronome.com> This allows GRE tunnels to send and receive both layer 2 packets (packets with an ethernet header) and layer 3 packets (packets without an ethernet header). Signed-off-by: Simon Horman <simon.hor...@netronome.com> Signed-off-by: J

[ovs-dev] [PATCH net-next v12 6/9] openvswitch: netlink: support L3 packets

and Simon Horman. Signed-off-by: Lorand Jakab <loja...@cisco.com> Signed-off-by: Simon Horman <simon.hor...@netronome.com> Signed-off-by: Jiri Benc <jb...@redhat.com> --- net/openvswitch/flow_netlink.c | 160 + 1 file changed, 99 insertion

[ovs-dev] [PATCH net-next v12 3/9] openvswitch: pass mac_proto to ovs_vport_send

packet. For example, ARPHRD_NONE tunnels that encapsulate Ethernet should get at least the Ethernet header. Signed-off-by: Jiri Benc <jb...@redhat.com> --- net/openvswitch/actions.c | 29 + net/openvswitch/vport.c | 2 +- net/openvswitch/vport.h | 2 +- 3

[ovs-dev] [PATCH net-next v12 4/9] openvswitch: support MPLS push and pop for L3 packets

Update Ethernet header only if there is one. Signed-off-by: Jiri Benc <jb...@redhat.com> --- net/openvswitch/actions.c | 18 +++--- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c index dc8bb97e2258..064cbc

[ovs-dev] [PATCH net-next v12 5/9] openvswitch: add processing of L3 packets

is not in place yet. Based on previous versions by Lorand Jakab and Simon Horman. Signed-off-by: Lorand Jakab <loja...@cisco.com> Signed-off-by: Simon Horman <simon.hor...@netronome.com> Signed-off-by: Jiri Benc <jb...@redhat.com> --- net/openvswitch/datapath.c | 17 ++-- net/

[ovs-dev] [PATCH net-next v12 1/9] openvswitch: use hard_header_len instead of hardcoded ETH_HLEN

packet going to L3 interface. Signed-off-by: Jiri Benc <jb...@redhat.com> --- net/openvswitch/actions.c | 3 ++- net/openvswitch/vport.c | 10 ++ 2 files changed, 8 insertions(+), 5 deletions(-) diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c index 1105c4

[ovs-dev] [PATCH net-next v12 2/9] openvswitch: add mac_proto field to the flow key

can just remove all those branches completely. Signed-off-by: Jiri Benc <jb...@redhat.com> --- There are three possible approaches: (1) The one in this patch. (2) Use just a one bit flag indicating whether the packet is L3 or Ethernet (similar to the "is_layer3" bool in v11)

[ovs-dev] [PATCH net-next v12 0/9] openvswitch: support for layer 3 encapsulated packets

patchset for Open vSwitch user space works with this submission unmodified. Jiri Benc (8): openvswitch: use hard_header_len instead of hardcoded ETH_HLEN openvswitch: add mac_proto field to the flow key openvswitch: pass mac_proto to ovs_vport_send openvswitch: support MPLS push and pop for L3

Re: [ovs-dev] [PATCH net-next v11 5/6] openvswitch: add layer 3 flow/port support

Reviving a very old thread, sorry. Simon handed this over to me, I'm preparing v12. On Fri, 15 Jul 2016 14:07:37 -0700, pravin shelar wrote: > I am not sure if you can use only mac_len to detect L3 packet. This > does not work with MPLS packets, mac_len is used to account MPLS > headers pushed on

Re: [ovs-dev] [PATCH net-next v21 3/4] openvswitch: 802.1AD Flow handling, actions, vlan parsing, netlink attributes

On Sat, 3 Sep 2016 13:30:12 -0400, Eric Garver wrote: > Would a BUG_ON(!(encap && in_encap)) be better? Please don't crash the kernel for something that could very well continue without problems. Use WARN_ON at most. And if you go that way, WARN_ON_ONCE or rate limiting seems to be even more

Re: [ovs-dev] [PATCH net-next v11 5/6] openvswitch: add layer 3 flow/port support

On Mon, 8 Aug 2016 17:17:17 +0200, Simon Horman wrote: > +bool skb_mac_header_present(struct sk_buff *skb) > +{ > + return skb->dev->type == ARPHRD_ETHER || > + (skb->dev->type == ARPHRD_NONE && > + skb->protocol == htons(ETH_P_TEB)); > +} >

Re: [ovs-dev] [PATCH net-next v11 5/6] openvswitch: add layer 3 flow/port support

On Mon, 18 Jul 2016 13:50:27 +0900, Simon Horman wrote: > On Fri, Jul 15, 2016 at 02:07:37PM -0700, pravin shelar wrote: > > I think we should send L2 header with l2 header pushed on skb. This is > > what OVS expect. The skb-push should be done for all l2 packets rather > > than for particular

  1   2   >