described about reading 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
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 u
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-b
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 yo
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 skb_push_nsh(
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;
> +
> +
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 conce
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
___
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
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
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;
> +
> +
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
___
dev mailing list
d...@openvswitch.org
https://mail.ope
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) {
> > +
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 b
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
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 tag
37 ("openvswitch: add processing of L3 packets")
> Signed-off-by: Eric Garver
Thanks!
Reviewed-by: Jiri Benc
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
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 it
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 attribut
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 at __ovs_nla_c
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.
Also
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 posting
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 attr
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 tun_metadat
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 OVS_ACTION_A
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
> +-- OVS_ACTION_ATTR_
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 w
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
> >
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
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, be
On Mon, 21 Aug 2017 14:11:10 +0800, Yang, Yi wrote:
> In OVS code, it has been removed because of Microsoft compiler issue.
We absolutely, completely and utterly do not care in the kernel. Please
never make such arguments and never make the code look worse because of
a compiler for other operating
On Mon, 21 Aug 2017 13:54:23 +0800, Yi Yang wrote:
> v4->v5
> - Fix many comments by Jiri Benc and Eric Garver
>for v4.
NACK for v5, we haven't finished discussing v4. You're sending new
versions too quickly.
My comment about sending a new version was meant only for
On Mon, 21 Aug 2017 16:39:01 +0800, Yang, Yi wrote:
> Anyway, we need to keep the code in userspace consistent with the one in
> kernel as possible as, otherwise it will be a burden for developer, I
> know userspace has different coding standard from kernel, this will make
> developer painful if we
On Mon, 21 Aug 2017 09:04:30 +, Jan Scheurich wrote:
> The second member of the union should be a variable length array []
> of struct nsh_md2_tlv
>
> struct nsh_hdr {
> ovs_be16 ver_flags_ttl_len;
> uint8_t mdtype;
> uint8_t np;
> ovs_16aligned_be32 path_hdr;
> union {
>
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 nsh_md2
On Mon, 21 Aug 2017 09:42:27 +, Jan Scheurich wrote:
> I understand your concern. But not declaring md2 as array is wrong as
> well, as there might not be an MD2 TLV context header. An MD2 NSH
> header is perfectly valid without any TLV. So in any case the user of
> the struct needs to be aware
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
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
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 prot
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;
> - __u8inner_
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 c
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
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/m
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 = nsh_hdr_l
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 ke
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
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. */
> + __OVS_NSH_KE
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
OVS_KEY_AT
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
> component
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
wh
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 ye
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. Alt
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
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.
> +
> + retur
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 packet
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 v
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 forth,
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.
On Tue, 10 Jan 2017 19:29:21 +0530, Pravin Shelar wrote:
> OVS kernel module has compile time checks for various kernel features,
> if any of required tunnel feature is missing OVS kernel module
> compiles in support for its own tunnel implementation. This compat
> tunnel implementation is exposed
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
On Tue, 10 Jan 2017 10:49:15 -0500, Eric Garver wrote:
> With Pravin's last feedback I think we can do the lwt probe on init as
> well.
Yes, we can.
> == On startup/init ==
>
> create an ovs_geneve interface using rtnetlink
> if successful {
> check parameters of the created interface
>
On Wed, 28 Dec 2016 20:26:28 +0800, Yi Yang wrote:
> --- a/datapath/linux/compat/include/linux/openvswitch.h
> +++ b/datapath/linux/compat/include/linux/openvswitch.h
> @@ -291,6 +291,7 @@ enum ovs_vport_attr {
> enum {
> OVS_VXLAN_EXT_UNSPEC,
> OVS_VXLAN_EXT_GBP, /* Flag or __u32
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 abilit
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 yo
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 -
>
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 =
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
the patchset. Another one is stricter checking of attributes (match on L2
vs. L3 packet) at the kernel level.
* Instead of is_layer3 bool, a mac_proto field is used.
Jiri Benc (8):
openvswitch: use hard_header_len instead of hardcoded ETH_HLEN
openvswitch: add mac_proto field to the flow ke
packet going to L3 interface.
Signed-off-by: Jiri Benc
Acked-by: Pravin B Shelar
---
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
t, we can just remove all those branches completely.
Signed-off-by: Jiri Benc
Acked-by: Pravin B Shelar
---
net/openvswitch/actions.c | 14 +++---
net/openvswitch/flow.c | 1 +
net/openvswitch/flow.h | 22 ++
net/openvswitch/flow_netlink.c
cular packet. For example, ARPHRD_NONE tunnels that encapsulate
Ethernet should get at least the Ethernet header.
Signed-off-by: Jiri Benc
Acked-by: Pravin B Shelar
---
net/openvswitch/actions.c | 29 +
net/openvswitch/vport.c | 2 +-
net/openvswitch/vport.h | 2
Update Ethernet header only if there is one.
Signed-off-by: Jiri Benc
Acked-by: Pravin B Shelar
---
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
in place yet.
Based on previous versions by Lorand Jakab and Simon Horman.
Signed-off-by: Lorand Jakab
Signed-off-by: Simon Horman
Signed-off-by: Jiri Benc
---
v13:
- fix incorrect setting of packet to NULL in ovs_packet_cmd_execute
- dropping packet for interfaces with wrong type
---
net
and Simon Horman.
Signed-off-by: Lorand Jakab
Signed-off-by: Simon Horman
Signed-off-by: Jiri Benc
Acked-by: Pravin B Shelar
---
net/openvswitch/flow_netlink.c | 160 +
1 file changed, 99 insertions(+), 61 deletions(-)
diff --git a/net/openvswitch
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
Signed-off-by: Simon Horman
Signed-off-by: Jiri Benc
Acked-by: Pravin B Shelar
---
net/openvswitch/vport-netdev.c | 9 ++---
1 file changed, 6
y: Lorand Jakab
Signed-off-by: Simon Horman
Signed-off-by: Jiri Benc
---
v13: use skb_reset_mac_len in push_eth and pop_eth
---
include/uapi/linux/openvswitch.h | 15
net/openvswitch/actions.c| 49
net/openvswitch/flow_n
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 mem
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
On Fri, 2 Dec 2016 15:32:24 +, Jan Scheurich wrote:
> However, I would still like to make the point that EXT-382 is
> designed to allow more flexibility for an OF controller to deal with
> encapsulation stacks.
"More flexibility" is not a holy grail. It makes sense only when it
brings some val
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
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
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 cre
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 that
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 unfortun
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 s
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 bum
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 = nla_get_be16(a[OVS_KEY_ATTR_VLAN
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 chos
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. Usersp
My comments apply more to the yet to be submitted kernel part. Until
then, I agree with Joe that all of this should be inside
#ifndef __KERNEL__. But these are comments I'd have at netdev thus you
may as well change that for v2 (or explain that I'm wrong).
On Wed, 5 Jul 2017 11:45:42 +0800, Yi Ya
88 matches
Mail list logo