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

[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 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 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 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

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] [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 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] [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] [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 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 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

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] 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] 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 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 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 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 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 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] 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 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 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 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 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] [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] 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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] 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 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 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 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 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 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] 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] 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 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] [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] 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] 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] [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 -