Re: [ovs-dev] ip route command not adding entry into ovs-appctl ovs/route/show

[Pravin Shelar]

On Thu, Feb 9, 2017 at 10:30 AM, Srikanth Lingala
 wrote:
> Hi,
> I am using OVS 2.6.1 which is installed on aarch64 Ubuntu 14.04 node.
> When I add a 'route' it is adding into linux routing table. But, when I 
> execute the command 'ovs-appctl ovs/route/show', that specific route is not 
> showing up.
> For example:
>
> root@node-14:~# route add -net 2.2.2.0 netmask 255.255.255.0 br-int
>
My guess is ovs-router is not able to find source ip address for the
network segment (2.2.2.0/24) for device br-int. You can confirm it by
trying same command on master branch with debug logging. OVS 2.6
router does not log such errors.

> root@node-14:~# route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric RefUse Iface
> 0.0.0.0 10.20.0.2   0.0.0.0 UG0  00 
> br-fw-admin
> 10.20.0.0   0.0.0.0 255.255.255.0   U 0  00 
> br-fw-admin
> 2.2.2.0   0.0.0.0 255.255.255.0   U 0  00 br-int
> 169.254.169.254 -   255.255.255.255 !H0  -0 -
> 192.168.0.0 0.0.0.0 255.255.255.0   U 0  00 
> br-mgmt
> 192.168.1.0 0.0.0.0 255.255.255.0   U 0  00 
> br-storage
> 192.168.2.0 0.0.0.0 255.255.255.0   U 0  00 
> br-mesh
>
> root@node-14:~# ovs-appctl ovs/route/show
> Route Table:
> Cached: 10.20.0.4/32 dev br-fw-admin SRC 10.20.0.4
> Cached: 127.0.0.1/32 dev lo SRC 127.0.0.1
> Cached: 192.168.0.4/32 dev br-mgmt SRC 192.168.0.4
> Cached: 192.168.1.2/32 dev br-storage SRC 192.168.1.2
> Cached: 192.168.2.2/32 dev br-mesh SRC 192.168.2.2
> Cached: ::1/128 dev lo SRC ::1
> Cached: fe80::20a:f7ff:fe2c:ca97/128 dev lo SRC ::1
> Cached: fe80::4c7:59ff:fe6b:1239/128 dev lo SRC ::1
> Cached: fe80::1c7b:80ff:fef0:9aed/128 dev lo SRC ::1
> Cached: fe80::1ce7:53ff:fe40:4223/128 dev lo SRC ::1
> Cached: fe80::2a02:4eff:fe49:3732/128 dev lo SRC ::1
> Cached: fe80::d44f:2fff:fe36:784c/128 dev lo SRC ::1
> Cached: fe80::d816:78ff:fef0:efe9/128 dev lo SRC ::1
> Cached: fe80::ec75:d2ff:fea6:9c22/128 dev lo SRC ::1
> Cached: fe80::fc16:3eff:fe18:f042/128 dev lo SRC ::1
> Cached: fe80::fc16:3eff:fe75:7aa3/128 dev lo SRC ::1
> Cached: fe80::fc16:3eff:fe84:e9b4/128 dev lo SRC ::1
> Cached: ff02::16/128 dev br-fw-admin SRC fe80::4c7:59ff:fe6b:1239
> Cached: ff02::1:ffaf:b669/128 dev br-fw-admin SRC fe80::4c7:59ff:fe6b:1239
> Cached: 10.20.0.0/24 dev br-fw-admin SRC 10.20.0.4
> Cached: 192.168.0.0/24 dev br-mgmt SRC 192.168.0.4
> Cached: 192.168.1.0/24 dev br-storage SRC 192.168.1.2
> Cached: 192.168.2.0/24 dev br-mesh SRC 192.168.2.2
> Cached: 127.0.0.0/8 dev lo SRC 127.0.0.1
> Cached: 0.0.0.0/0 dev br-fw-admin GW 10.20.0.2 SRC 10.20.0.4
> Cached: fe80::/64 dev br-int SRC fe80::2a02:4eff:fe49:3732
> Cached: ff00::/8 dev br-int SRC fe80::2a02:4eff:fe49:3732
>
> Can someone give me a clue to debug the issue?
>
> Thanks for the help.
>
> Regards,
> Srikanth.
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] dpdk: Improve manpage for dpdk memory configuration.

[nickcooper-zhangtonghao]

Signed-off-by: nickcooper-zhangtonghao 
---
 vswitchd/vswitch.xml | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml
index 146a816..a3beafd 100644
--- a/vswitchd/vswitch.xml
+++ b/vswitchd/vswitch.xml
@@ -241,10 +241,6 @@
   regardless of socket. It is recommended that dpdk-socket-mem is used
   instead.
 
-
-  If not specified, the value is 0. Changing this value requires
-  restarting the daemon.
-
   
 
   
 
-  If not specified, the default value is 1024,0. Changing this value
-  requires restarting the daemon.
+  If dpdk-socket-mem and dpdk-alloc-mem are not specified, 
dpdk-socket-mem
+  will be used and the default value is 1024,0. If dpdk-socket-mem and
+  dpdk-alloc-mem are specified at same time, dpdk-socket-mem will be
+  used as default. Changing this value requires restarting the daemon.
 
   
 
-- 
1.8.3.1



___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs

[Yang, Yi Y]

Joe, thank you for explanation, let us push 802.1ad backport patches first, 
Eric Garver has acked two of them, I'll rework another one patch he commented. 
What Valentine mentioned has no business with 802.1 ad, it is what we want to 
consider after Eric Garver's rtnetlink userspace patches are merged, we have no 
way to use in-kernel data path to do it without rtnetlink userspace patches.

Can you point out which patches  for 802.1ad are missing? I almost checked all 
the 802.1 ad patches, ovs doesn't use most of them, most of them make nonsense 
to ovs. Eric, please help point out if I missed something.

-Original Message-
From: Joe Stringer [mailto:j...@ovn.org] 
Sent: Friday, February 10, 2017 8:01 AM
To: Yang, Yi Y 
Cc: ovs dev ; Yi-Hung Wei 
Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs

On 8 February 2017 at 18:50, Yang, Yi Y  wrote:
> Then, are you merging 
> https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328492.html or 
> do I need to do anything else for it?

It looks like the backport breaks the existing kernel module tests on older 
kernels, without even using the new functionality. I've provided feedback on 
how you might further dig into that, and I don't believe I've seen confirmation 
that you observe the same thing, or any proposed solutions.

I've mentioned previously a preference to see patches backported in the 
canonical order. I believe there's just a few patches missing from before 
802.1ad, and discussions are ongoing to address those backports. I expect with 
time, those will be proposed and merged, and then we can look at 802.1ad.

Finally, patches always need review before merging. Given that others in the 
community have previously looked into 802.1ad, I was looking to see that people 
with more detailed knowledge of these codepaths would take a first look. I see 
that Eric has now done so, and there is feedback to address. I also see that 
Valentine has provided some feedback.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs

[Yang, Yi Y]

Ok, let me push 802.1 ad backport patches first.

-Original Message-
From: Jan Scheurich [mailto:jan.scheur...@web.de] 
Sent: Friday, February 10, 2017 7:04 AM
To: Yang, Yi Y ; Jan Scheurich 
; Joe Stringer ; Jiri Benc 
(jb...@redhat.com) ; Eric Garver ; 
'ja...@ovn.org' 
Cc: d...@openvswitch.org
Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs

Hi Yi,

I suggest we include (adapted versions of) your vxlan-gpe user space patches 
into the new L3 tunneling user-space series when we respin v2 with the review 
comments. Thus we get rid of one dependency. And you can focus on the datapath 
backports and NSH. Do you agree?

@Jarno: It would be great if you could find the time to review the new series.

Thanks, Jan

On 2017-02-09 11:46, Yang, Yi Y wrote:
> Jan, I'm ok, I will rebase those patches once ovs maintainers merge your 
> patches first. In my patches, I added vxlan-gpe user space support, that 
> needs those three user space patches, that is why I included those three user 
> space patches in my patch set.
>
> I don't know what order ovs maintainers will merge them in. I can only focus 
> on userspace support for vxlan-gpe if ovs maintainers really merge your 
> patches first.
>
> -Original Message-
> From: Jan Scheurich [mailto:jan.scheur...@ericsson.com]
> Sent: Thursday, February 9, 2017 5:50 PM
> To: Yang, Yi Y ; Joe Stringer ; Jiri 
> Benc (jb...@redhat.com) ; Eric Garver 
> Cc: d...@openvswitch.org; Jarno Rajahalme (ja...@ovn.org) 
> 
> Subject: RE: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset 
> to ovs
>
> Hi Yi,
>
> I very much doubt that it makes sense to first merge the obsolete user-space 
> patches and then override them with the target version.
>
> Jarno and Joe have in principle agreed to merge the new user-space patches 
> independently of the backport of the kernel datapath patches. So there is no 
> dependency in this direction.
>
> If it is not possible to merge the kernel datapath back-ports without test 
> cases, then I think the datapath merge should wait for the merge of the new 
> user-space patches and then add end-to-end test cases for the kernel datapath 
> as well.
>
> But perhaps such end-to-end tests are not strictly necessary. It appears to 
> me that Jiri's L3 tunneling datapath patches were merged into net-next 
> without such test cases (just based on code review). So why not in OVS tree?
>
> We can then add end-to-end kernel datapath tests when the Eric's outstanding 
> user-space patches for rtnetlink and compat tunnel configuration for L3 
> tunnels are added.
>
> BR, Jan
>
>
>> -Original Message-
>> From: Yang, Yi Y [mailto:yi.y.y...@intel.com]
>> Sent: Wednesday, 08 February, 2017 06:31
>> To: Jan Scheurich ; Joe Stringer 
>> ; Jiri Benc (jb...@redhat.com) ; Eric 
>> Garver 
>> Cc: d...@openvswitch.org
>> Subject: RE: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset 
>> to ovs
>>
>> I'll check how we can rebase your changes against those three patches 
>> on top of my patches, our goals are same, that is to merge your 
>> changes and this patch set to ovs. I don't know what order Joe will merge 
>> them in. Obviously one patch set can't depend on another one which isn't 
>> nailed down to merge or not.
>>
>> Jan, let us have a sync by lync meeting.
>>
>> -Original Message-
>> From: Jan Scheurich [mailto:jan.scheur...@ericsson.com]
>> Sent: Wednesday, February 8, 2017 7:19 AM
>> To: Joe Stringer ; Yang, Yi Y ; 
>> Jiri Benc (jb...@redhat.com) ; Eric Garver 
>> 
>> Cc: d...@openvswitch.org
>> Subject: RE: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset 
>> to ovs
>>
>> Hi Yi,
>>
>> Both Joe and Jarno have indicated there are no principle problems 
>> merging our self-contained user-space patches for L3 tunneling. May I 
>> suggest that you (together with Jiri and Eric) focus on the datapath 
>> back-ports and the user-space patches on top needed to configure L3 tunnels 
>> in the net-next and OVS tree kernel module.
>>
>> /Jan
>>
>>> -Original Message-
>>> From: Joe Stringer [mailto:j...@ovn.org]
>>> Sent: Tuesday, 07 February, 2017 18:55
>>> To: Yang, Yi Y 
>>> Cc: Jan Scheurich ; d...@openvswitch.org
>>> Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset 
>>> to ovs
>>>
>>> On 7 February 2017 at 05:28, Yang, Yi Y  wrote:
 Jan, I know that, but per Joe's comments, it seems he won't merge your 
 patch set unless the part in kernel side is merged before them.
>>> It can't work without these three patches.
>>>
>>> I have primarily expressed concern about 

Re: [ovs-dev] [PATCH v2 3/4] datapath: backport: vlan: Check for vlan ethernet types for 8021.q or 802.1ad

[Yang, Yi Y]

Thanks Eric, I see, they were missing, I'll add them as you said.

-Original Message-
From: Eric Garver [mailto:e...@erig.me] 
Sent: Thursday, February 9, 2017 11:37 PM
To: Yang, Yi Y 
Cc: d...@openvswitch.org
Subject: Re: [ovs-dev] [PATCH v2 3/4] datapath: backport: vlan: Check for vlan 
ethernet types for 8021.q or 802.1ad

On Mon, Feb 06, 2017 at 08:36:50PM +0800, Yi Yang wrote:
> commit fe19c4f971a55cea3be442d8032a5f6021702791
> Author: Eric Garver 
> Date:   Wed Sep 7 12:56:58 2016 -0400
> 
> This is to simplify using double tagged vlans. This function allows all
> valid vlan ethertypes to be checked in a single function call.
> Also replace some instances that check for both ETH_P_8021Q and
> ETH_P_8021AD.
> 
> Patch based on one originally by Thomas F Herbert.
> 
> Signed-off-by: Thomas F Herbert 
> Signed-off-by: Eric Garver 
> Acked-by: Pravin B Shelar 
> Signed-off-by: David S. Miller 
> 
> Signed-off-by: Yi Yang 
> ---
>  acinclude.m4  |  1 +
>  datapath/linux/compat/include/linux/if_vlan.h | 24 
> +---
>  2 files changed, 22 insertions(+), 3 deletions(-)
> 
> diff --git a/acinclude.m4 b/acinclude.m4 index 9166da8..f219bec 100644
> --- a/acinclude.m4
> +++ b/acinclude.m4
> @@ -664,6 +664,7 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
>OVS_GREP_IFELSE([$KSRC/include/linux/if_vlan.h], [__vlan_insert_tag])
>OVS_GREP_IFELSE([$KSRC/include/linux/if_vlan.h], [vlan_get_protocol])
>OVS_GREP_IFELSE([$KSRC/include/linux/if_vlan.h], [skb_vlan_tagged])
> +  OVS_GREP_IFELSE([$KSRC/include/linux/if_vlan.h], [eth_type_vlan])
>  
>OVS_GREP_IFELSE([$KSRC/include/linux/u64_stats_sync.h], 
> [u64_stats_fetch_begin_irq])
>  
> diff --git a/datapath/linux/compat/include/linux/if_vlan.h 
> b/datapath/linux/compat/include/linux/if_vlan.h
> index c8ddef1..ff55fb8 100644
> --- a/datapath/linux/compat/include/linux/if_vlan.h
> +++ b/datapath/linux/compat/include/linux/if_vlan.h
> @@ -100,6 +100,25 @@ static inline struct sk_buff 
> *rpl___vlan_hwaccel_put_tag(struct sk_buff *skb,  #define 
> __vlan_hwaccel_put_tag rpl___vlan_hwaccel_put_tag  #endif
>  
> +#ifndef HAVE_ETH_TYPE_VLAN
> +/**
> + * eth_type_vlan - check for valid vlan ether type.
> + * @ethertype: ether type to check
> + *
> + * Returns true if the ether type is a vlan ether type.
> + */
> +static inline bool eth_type_vlan(__be16 ethertype) {
> + switch (ethertype) {
> + case htons(ETH_P_8021Q):
> + case htons(ETH_P_8021AD):
> + return true;
> + default:
> + return false;
> + }
> +}
> +#endif
> +
>  /* All of these were introduced in a single commit preceding 2.6.33, so
>   * presumably all of them or none of them are present. */  #ifndef 
> VLAN_PRIO_MASK @@ -188,7 +207,7 @@ static inline __be16 
> __vlan_get_protocol(struct sk_buff *skb, __be16 type,
>* present at mac_len - VLAN_HLEN (if mac_len > 0), or at
>* ETH_HLEN otherwise
>*/
> - if (type == htons(ETH_P_8021Q) || type == htons(ETH_P_8021AD)) {
> + if (eth_type_vlan(type)) {
>   if (vlan_depth) {
>   if (WARN_ON(vlan_depth < VLAN_HLEN))
>   return 0;
> @@ -206,8 +225,7 @@ static inline __be16 __vlan_get_protocol(struct sk_buff 
> *skb, __be16 type,
>   vh = (struct vlan_hdr *)(skb->data + vlan_depth);
>   type = vh->h_vlan_encapsulated_proto;
>   vlan_depth += VLAN_HLEN;
> - } while (type == htons(ETH_P_8021Q) ||
> -  type == htons(ETH_P_8021AD));
> + } while (eth_type_vlan(type));
>   }
>  
>   if (depth)

I think you can also take the hunks for skb_vlan_tagged() and
skb_vlan_tagged_multi() since you add them in the previous patch.

__vlan_get_tag() isn't in the OVS datapath, so that hunk can be omitted.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] compat: Remove rpl_dev_queue_xmit() backport.

[Joe Stringer]

On 9 February 2017 at 02:20, Simon Horman  wrote:
> Hi Joe,
>
> On Wed, Feb 08, 2017 at 04:50:36PM -0800, Joe Stringer wrote:
>> The MPLS portions of this were inadvertently broken in v2.4 due to
>> 433637881ca5 ("datapath: define compat __skb_gso_segment()") which
>> inverts the supports_mpls_gso() logic, then when rpl_dev_queue_xmit()
>> backport dropped its VLAN portion in v2.6, the whole function became a
>> no-op - since b63bf2488209 ("datapath: remove VLAN compat code from GSO").
>>
>> Apparently the MPLS side of this code never worked in a released version
>> of OVS and no-one noticed, so remove it.
>>
>> Signed-off-by: Joe Stringer 
>> ---
>> CC: Simon Horman 
>>
>> Simon, I'm not sure what the repercussions are of this but by my reading
>> of the code the extra skb_gso_segment compat code here is never invoked
>> anyway so I figure we can just drop it. Looks like it might've been
>> fine when originally submitted, but by the time v2.4 came out it was
>> already nerfed >.<
>>
>> That said, if we just need to fix the version check to get it working
>> again then that's an option.
>
> True. I'm pretty sure I exercised the code in question at some point so I
> think it ought to work modulo being disabled. But of course some testing
> would be required.  Probably this would be worth doing as unexpected GSO
> failures are somewhat hard to track down IMHO.  That said, I don't feel
> strongly about this given that it only affects what by now are rather old
> kernels and no one seems to have reported a problem.

OK. Do you have an idea of what the behaviour is given that this
backport isn't working correctly? If it's just slower but with the
correct behaviour, then given no-one noticed I think it's safe to just
remove. If there's packet corruption or drop (or worse, crash), then
we probably want to do better.

> Do you have any view on how much longer kernels older than v3.19 will be
> supported by OvS?

I don't have a concrete answer for you on that. One way to look at it
is that supporting new features on these older kernels takes a certain
amount of effort. If lots of people are running those kernels (eg
CentOS w/ 3.10 or Ubuntu w/ 3.13), and the effort is reasonably small
then it's probably worthwhile to continue to backport. If those
kernels are less widely used, or if backporting newer code to those
older kernels becomes a massive undertaking, then it'd be worth
considering which kernels are worth spending time on. To some degree,
we can make this determination on a feature-by-feature basis (eg, we
add a new feature but only enable it if your kernel is X or newer);
but there are dangers there around code complexity and debuggability
of different feature combinations so this approach is typically
avoided.

>> Also, I see that the upstream commit
>> 48d2ab609b6b ("net: mpls: Fixups for GSO") will further change the way
>> that OVS deals with MPLS GSO, so perhaps we'll actually need to bring
>> back a backport for handling those cases, when that patch is backported
>> to the OVS tree.
>
> Yes, it seems likely that OvS would need some compatibility code to handle
> that change - and IIRC some related changes to catch all the corner cases.

If you're referring to the followup fixes for that patch, then yes. If
you've got something else in mind regarding corner cases, I'd be
interested to hear what those are.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs

[Joe Stringer]

On 8 February 2017 at 18:50, Yang, Yi Y  wrote:
> Then, are you merging 
> https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328492.html or 
> do I need to do anything else for it?

It looks like the backport breaks the existing kernel module tests on
older kernels, without even using the new functionality. I've provided
feedback on how you might further dig into that, and I don't believe
I've seen confirmation that you observe the same thing, or any
proposed solutions.

I've mentioned previously a preference to see patches backported in
the canonical order. I believe there's just a few patches missing from
before 802.1ad, and discussions are ongoing to address those
backports. I expect with time, those will be proposed and merged, and
then we can look at 802.1ad.

Finally, patches always need review before merging. Given that others
in the community have previously looked into 802.1ad, I was looking to
see that people with more detailed knowledge of these codepaths would
take a first look. I see that Eric has now done so, and there is
feedback to address. I also see that Valentine has provided some
feedback.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v4] dpif-netdev: Conditional EMC insert

[Jan Scheurich]

I was also struggling a bit with this conceptual mismatch.

N really is the reciprocal probability (P = 1/N), and values above a few 
1000s are probably not very meaningful.


Specifying in P in percent is certainly easier to understand, the only 
issue I have is that integer values would limit us to P >= 1%. Would it 
be an option to specify P in percent but allow floating point values, so 
that one could say other_config:emc-insert-prob=0.1 for P = 1/1000?


BR, Jan

On 2017-02-09 11:30, Ilya Maximets wrote:

Hi, Ciara.


+EMC Insertion Probability
+-
+By default 1 in every 100 flows are inserted into the Exact Match Cache (EMC).
+It is possible to change this insertion probability by setting the
+``emc-insert-prob`` option::
+
+$ ovs-vsctl --no-wait set Open_vSwitch . other_config:emc-insert-prob=N
+
+where:
+
+``N``
+  is a positive integer between 0 and 4294967295 (maximum unsigned 32bit int).
+
+If ``N`` is set to 1, an insertion will be performed for every flow. The lower
+the value of ``emc-insert-prob`` the higher the probability of insertion,
+except for the value 0 which will result in no insertions being performed and
+thus essentially disabling the EMC.

I totally don't understand why 'N' is an integer between 0 and 4294967295.
Why we can't just use 0-100% for that config?

Probability in math is a value between 0 and 1. We can use an integer values
from 0 to 100 in percents. IMHO, that strange configuration kind of misleading
because 'emc-insert-prob' reads as 'emc-insert-probability' but means something
completely different. Also, does all of this values from 0 to 4294967295 are 
useful?

What do you think?

Best regards, Ilya Maximets.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs

[Jan Scheurich]

Hi Valentine,

On 2017-02-09 08:58, Valentine Sinitsyn wrote:
This L3 patchset looks similar to what we did internally with OVS 2.6 
to add support for IPv6 tunnels.


Could you please confirm that ovs-dpctl reports correct statistics 
with this patchset when one uses in-kernel Linux datapath? We had some 
issues with this (the counters were always zero). Largely, this was 
because userspace code (I refer to the tools and the daemon, not DPDK 
datapath here) assumes a plugged network interface is always L2, and I 
don't see this patch touching these files.


The most recent user-space code in vswitchd that deals with the L3 
tunnels in netdev and kernel datapath is contained in another patch 
series: 
https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328391.html


You could help in reviewing that. It may not be complete with respect to 
handling kernel datapath tunnels as we were not able to test yet due to 
a lack of patches to configure L3 tunnel ports in the kernel. But 
similar problems with counters might also exist with netdev datapath.


Thanks, Jan

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs

[Jan Scheurich]

Hi Yi,

I suggest we include (adapted versions of) your vxlan-gpe user space 
patches into the new L3 tunneling user-space series when we respin v2 
with the review comments. Thus we get rid of one dependency. And you can 
focus on the datapath backports and NSH. Do you agree?


@Jarno: It would be great if you could find the time to review the new 
series.


Thanks, Jan

On 2017-02-09 11:46, Yang, Yi Y wrote:

Jan, I'm ok, I will rebase those patches once ovs maintainers merge your 
patches first. In my patches, I added vxlan-gpe user space support, that needs 
those three user space patches, that is why I included those three user space 
patches in my patch set.

I don't know what order ovs maintainers will merge them in. I can only focus on 
userspace support for vxlan-gpe if ovs maintainers really merge your patches 
first.

-Original Message-
From: Jan Scheurich [mailto:jan.scheur...@ericsson.com]
Sent: Thursday, February 9, 2017 5:50 PM
To: Yang, Yi Y ; Joe Stringer ; Jiri Benc 
(jb...@redhat.com) ; Eric Garver 
Cc: d...@openvswitch.org; Jarno Rajahalme (ja...@ovn.org) 
Subject: RE: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs

Hi Yi,

I very much doubt that it makes sense to first merge the obsolete user-space 
patches and then override them with the target version.

Jarno and Joe have in principle agreed to merge the new user-space patches 
independently of the backport of the kernel datapath patches. So there is no 
dependency in this direction.

If it is not possible to merge the kernel datapath back-ports without test 
cases, then I think the datapath merge should wait for the merge of the new 
user-space patches and then add end-to-end test cases for the kernel datapath 
as well.

But perhaps such end-to-end tests are not strictly necessary. It appears to me 
that Jiri's L3 tunneling datapath patches were merged into net-next without 
such test cases (just based on code review). So why not in OVS tree?

We can then add end-to-end kernel datapath tests when the Eric's outstanding 
user-space patches for rtnetlink and compat tunnel configuration for L3 tunnels 
are added.

BR, Jan



-Original Message-
From: Yang, Yi Y [mailto:yi.y.y...@intel.com]
Sent: Wednesday, 08 February, 2017 06:31
To: Jan Scheurich ; Joe Stringer
; Jiri Benc (jb...@redhat.com) ; Eric
Garver 
Cc: d...@openvswitch.org
Subject: RE: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset
to ovs

I'll check how we can rebase your changes against those three patches
on top of my patches, our goals are same, that is to merge your
changes and this patch set to ovs. I don't know what order Joe will merge them 
in. Obviously one patch set can't depend on another one which isn't nailed down 
to merge or not.

Jan, let us have a sync by lync meeting.

-Original Message-
From: Jan Scheurich [mailto:jan.scheur...@ericsson.com]
Sent: Wednesday, February 8, 2017 7:19 AM
To: Joe Stringer ; Yang, Yi Y ; Jiri
Benc (jb...@redhat.com) ; Eric Garver 
Cc: d...@openvswitch.org
Subject: RE: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset
to ovs

Hi Yi,

Both Joe and Jarno have indicated there are no principle problems
merging our self-contained user-space patches for L3 tunneling. May I
suggest that you (together with Jiri and Eric) focus on the datapath back-ports 
and the user-space patches on top needed to configure L3 tunnels in the 
net-next and OVS tree kernel module.

/Jan


-Original Message-
From: Joe Stringer [mailto:j...@ovn.org]
Sent: Tuesday, 07 February, 2017 18:55
To: Yang, Yi Y 
Cc: Jan Scheurich ; d...@openvswitch.org
Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset
to ovs

On 7 February 2017 at 05:28, Yang, Yi Y  wrote:

Jan, I know that, but per Joe's comments, it seems he won't merge your patch 
set unless the part in kernel side is merged before them.

It can't work without these three patches.

I have primarily expressed concern about missing kernel patch
backports due to inconsistent backporting order. If Jan's series is
decoupled and still builds OK, tests OK, passes review, etc by
itself then I'm not sure I understand the dependency on the kernel patches.

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] rhel: remove duplicate line from rhel/automake.mk

[Lance Richardson]

Fixes: commit 55f36be59122 ("rhel: Firewall service files for OVN.")
Signed-off-by: Lance Richardson 
---
 rhel/automake.mk | 1 -
 1 file changed, 1 deletion(-)

diff --git a/rhel/automake.mk b/rhel/automake.mk
index df4c19a..c4f043a 100644
--- a/rhel/automake.mk
+++ b/rhel/automake.mk
@@ -31,7 +31,6 @@ EXTRA_DIST += \
rhel/usr_lib_systemd_system_ovn-controller.service \
rhel/usr_lib_systemd_system_ovn-controller-vtep.service \
rhel/usr_lib_systemd_system_ovn-northd.service \
-   rhel/usr_lib_systemd_system_ovn-northd.service \
rhel/usr_lib_firewalld_services_ovn-central-firewall-service.xml \
rhel/usr_lib_firewalld_services_ovn-host-firewall-service.xml
 
-- 
2.5.5

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] windows: netdev report error if query failed

[Alin Serdean]

Thanks a lot!

From: Guru Shetty [mailto:g...@ovn.org]
Sent: Thursday, February 9, 2017 8:40 PM
To: Alin Serdean 
Cc: d...@openvswitch.org
Subject: Re: [ovs-dev] [PATCH] windows: netdev report error if query failed



On 9 February 2017 at 08:23, Alin Serdean 
> wrote:
Thanks Guru.

Can you please apply 
https://github.com/openvswitch/ovs/commit/583d34678d32482d616fe5bd7dc323f044788898
 on branch-2.6 ?
Done. Thanks.


___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] windows: netdev report error if query failed

[Guru Shetty]

On 9 February 2017 at 08:23, Alin Serdean 
wrote:

> Thanks Guru.
>
>
>
> Can you please apply https://github.com/openvswitch/ovs/commit/
> 583d34678d32482d616fe5bd7dc323f044788898 on branch-2.6 ?
>
Done. Thanks.

>
>
> Thanks,
>
> Alin.
>
>
>
> *From:* Guru Shetty [mailto:g...@ovn.org]
> *Sent:* Wednesday, February 8, 2017 8:19 PM
> *To:* Alin Serdean 
> *Cc:* d...@openvswitch.org
> *Subject:* Re: [ovs-dev] [PATCH] windows: netdev report error if query
> failed
>
>
>
>
>
>
>
> On 7 February 2017 at 22:41, Alin Serdean 
> wrote:
>
> The netdev Windows construct uses query_netdev to see if a port exists
> in the datapath, in the case an error occurred in the reply message
> we returned 0, meaning netdev_open was successful.
>
> This patch fixes fixes that problem.
>
> Reported-at: https://github.com/openvswitch/ovs-issues/issues/125
> Reported-by
> :
> Shashank Ram 
> Signed-off-by: Alin Gabriel Serdean 
> ---
> intended for: branch-2.5, branch-2.6, branch-2.7, master
>
> Thanks, applied to all the above branches.
>
>
>
> ---
>  lib/netdev-windows.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/netdev-windows.c b/lib/netdev-windows.c
> index c2fbe42..b22bd09 100644
> --- a/lib/netdev-windows.c
> +++ b/lib/netdev-windows.c
> @@ -295,7 +295,7 @@ query_netdev(const char *devname,
>  }
>  }
>
> -return 0;
> +return error;
>  }
>
>  static void
> --
> 2.10.2.windows.1
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
>
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] ip route command not adding entry into ovs-appctl ovs/route/show

[Srikanth Lingala]

Hi,
I am using OVS 2.6.1 which is installed on aarch64 Ubuntu 14.04 node.
When I add a 'route' it is adding into linux routing table. But, when I execute 
the command 'ovs-appctl ovs/route/show', that specific route is not showing up.
For example:

root@node-14:~# route add -net 2.2.2.0 netmask 255.255.255.0 br-int

root@node-14:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
0.0.0.0 10.20.0.2   0.0.0.0 UG0  00 
br-fw-admin
10.20.0.0   0.0.0.0 255.255.255.0   U 0  00 
br-fw-admin
2.2.2.0   0.0.0.0 255.255.255.0   U 0  00 br-int
169.254.169.254 -   255.255.255.255 !H0  -0 -
192.168.0.0 0.0.0.0 255.255.255.0   U 0  00 br-mgmt
192.168.1.0 0.0.0.0 255.255.255.0   U 0  00 
br-storage
192.168.2.0 0.0.0.0 255.255.255.0   U 0  00 br-mesh

root@node-14:~# ovs-appctl ovs/route/show
Route Table:
Cached: 10.20.0.4/32 dev br-fw-admin SRC 10.20.0.4
Cached: 127.0.0.1/32 dev lo SRC 127.0.0.1
Cached: 192.168.0.4/32 dev br-mgmt SRC 192.168.0.4
Cached: 192.168.1.2/32 dev br-storage SRC 192.168.1.2
Cached: 192.168.2.2/32 dev br-mesh SRC 192.168.2.2
Cached: ::1/128 dev lo SRC ::1
Cached: fe80::20a:f7ff:fe2c:ca97/128 dev lo SRC ::1
Cached: fe80::4c7:59ff:fe6b:1239/128 dev lo SRC ::1
Cached: fe80::1c7b:80ff:fef0:9aed/128 dev lo SRC ::1
Cached: fe80::1ce7:53ff:fe40:4223/128 dev lo SRC ::1
Cached: fe80::2a02:4eff:fe49:3732/128 dev lo SRC ::1
Cached: fe80::d44f:2fff:fe36:784c/128 dev lo SRC ::1
Cached: fe80::d816:78ff:fef0:efe9/128 dev lo SRC ::1
Cached: fe80::ec75:d2ff:fea6:9c22/128 dev lo SRC ::1
Cached: fe80::fc16:3eff:fe18:f042/128 dev lo SRC ::1
Cached: fe80::fc16:3eff:fe75:7aa3/128 dev lo SRC ::1
Cached: fe80::fc16:3eff:fe84:e9b4/128 dev lo SRC ::1
Cached: ff02::16/128 dev br-fw-admin SRC fe80::4c7:59ff:fe6b:1239
Cached: ff02::1:ffaf:b669/128 dev br-fw-admin SRC fe80::4c7:59ff:fe6b:1239
Cached: 10.20.0.0/24 dev br-fw-admin SRC 10.20.0.4
Cached: 192.168.0.0/24 dev br-mgmt SRC 192.168.0.4
Cached: 192.168.1.0/24 dev br-storage SRC 192.168.1.2
Cached: 192.168.2.0/24 dev br-mesh SRC 192.168.2.2
Cached: 127.0.0.0/8 dev lo SRC 127.0.0.1
Cached: 0.0.0.0/0 dev br-fw-admin GW 10.20.0.2 SRC 10.20.0.4
Cached: fe80::/64 dev br-int SRC fe80::2a02:4eff:fe49:3732
Cached: ff00::/8 dev br-int SRC fe80::2a02:4eff:fe49:3732

Can someone give me a clue to debug the issue?

Thanks for the help.

Regards,
Srikanth.

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 1/1] doc: Clarify how user space is experimental.

[Joe Stringer]

On 9 February 2017 at 00:46, Stokes, Ian  wrote:
>> On 8 February 2017 at 02:08, Ian Stokes  wrote:
>> > Clarify that the use of the user space datapath with non DPDK devices
>> > is considered experimental.
>> >
>> > Fixes: 602e24ee189b (doc: Remove experimental warning for DPDK.)
>> > Signed-off-by: Ian Stokes 
>> > Co-authored-by: Joe Stringer 
>> > ---
>>
>> I suspect this got caught up in the ovs-dev filter, but it looks good to
>> me so I applied this to master and branch-2.7.
>
> Thanks Joe,
>
> I can see it on the 2.7 branch but not master, did it fail to apply? I can 
> re-submit if needs be.

Good catch, I got distracted literally half way through pushing to
master. It's there now:

https://github.com/openvswitch/ovs/commit/389e90e37d61e087f4edf36e400caa1752e69b6a
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] windows: netdev report error if query failed

[Alin Serdean]

Thanks Guru.

Can you please apply 
https://github.com/openvswitch/ovs/commit/583d34678d32482d616fe5bd7dc323f044788898
 on branch-2.6 ?

Thanks,
Alin.

From: Guru Shetty [mailto:g...@ovn.org]
Sent: Wednesday, February 8, 2017 8:19 PM
To: Alin Serdean 
Cc: d...@openvswitch.org
Subject: Re: [ovs-dev] [PATCH] windows: netdev report error if query failed



On 7 February 2017 at 22:41, Alin Serdean 
> wrote:
The netdev Windows construct uses query_netdev to see if a port exists
in the datapath, in the case an error occurred in the reply message
we returned 0, meaning netdev_open was successful.

This patch fixes fixes that problem.

Reported-at: https://github.com/openvswitch/ovs-issues/issues/125
Reported-by: Shashank Ram >
Signed-off-by: Alin Gabriel Serdean 
>
---
intended for: branch-2.5, branch-2.6, branch-2.7, master
Thanks, applied to all the above branches.

---
 lib/netdev-windows.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/netdev-windows.c b/lib/netdev-windows.c
index c2fbe42..b22bd09 100644
--- a/lib/netdev-windows.c
+++ b/lib/netdev-windows.c
@@ -295,7 +295,7 @@ query_netdev(const char *devname,
 }
 }

-return 0;
+return error;
 }

 static void
--
2.10.2.windows.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] Competencias del comprador exitoso

[Compras - 12 Temas Enfocados al área]

Beneficie a todo su equipo durante tres meses, ¡por un precio espectacular!

Programa Integral de Capacitación Online indispensable para los responsables de 
COMPRAS.

10 Conferencias pregrabadas inéditas para capacitar a todo el personal


Con este Programa Integral de Capacitación Online especializada usted, junto 
con sus colaboradores podrá obtener 12 Conferencias Online con duración de 2 a 
3 horas cada una, diseñadas por especialistas en la materia que le ayudarán a 
tener un panorama de actualización integral ¡único en el mercado!, al tener 
acceso las 24 horas del día, esté donde esté.

Si desea que le adjuntemos el temario Sin compromiso responda este correo con 
la palabra: Plan - Compras, juntos con los datos solicitados.

Nombre:
Teléfono:
Correo:

centro telefónico: 018002129393



___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v7] dpif-netdev: Conditional EMC insert

[Ciara Loftus]

Unconditional insertion of EMC entries results in EMC thrashing at high
numbers of parallel flows. When this occurs, the performance of the EMC
often falls below that of the dpcls classifier, rendering the EMC
practically useless.

Instead of unconditionally inserting entries into the EMC when a miss
occurs, use a 1% probability of insertion. This ensures that the most
frequent flows have the highest chance of creating an entry in the EMC,
and the probability of thrashing the EMC is also greatly reduced.

The probability of insertion is configurable, via the
other_config:emc-insert-prob option. For example the following command
increases the insertion probability to 10%.

ovs-vsctl set Open_vSwitch . other_config:emc-insert-prob=10

Signed-off-by: Ciara Loftus 
Signed-off-by: Georg Schmuecking 
Co-authored-by: Georg Schmuecking 
---
v7:
- Remove further code duplication
v6:
- Refactor the code to remove duplication around calls to
  emc_probabilistic_insert()
v5:
- Use percentiles for emc-insert-prob (0-100%)
- Update docs to reflect the option not exclusive to the DPDK datapath.
v4:
- Added Georg to Authors file
- Set emc-insert-prob=1 for 'PMD - stats' unit test
- Use read_relaxed on atomic var
- Correctly allow for 0 and 100% probababilites
- Cache align new element in dp_netdev struct
- Revert to default probability if invalid emc-insert-prob set
- Allow configurability for non-DPDK case
v3:
- Use new dpif other_config infrastructure to tidy up how the
  emc-insert-prob value is passed to dpif-netdev.
v2:
- Enable probability configurability via other_config:emc-insert-prob
  option.

 AUTHORS.rst  |  1 +
 Documentation/howto/dpdk.rst | 19 +
 NEWS |  2 ++
 lib/dpif-netdev.c| 50 
 tests/pmd.at |  1 +
 vswitchd/vswitch.xml | 13 
 6 files changed, 82 insertions(+), 4 deletions(-)

diff --git a/AUTHORS.rst b/AUTHORS.rst
index b567fcc..3382ad8 100644
--- a/AUTHORS.rst
+++ b/AUTHORS.rst
@@ -382,6 +382,7 @@ Eric Lopez  elo...@nicira.com
 Frido Roose fr.ro...@gmail.com
 Gaetano Catalli gaetano.cata...@gmail.com
 Gavin Remaley   gavin_rema...@selinc.com
+Georg Schmuecking   georg.schmueck...@ericsson.com
 George Shuklin  ama...@desunote.ru
 Gerald Rogers   gerald.rog...@intel.com
 Ghanem Bahribahri.gha...@gmail.com
diff --git a/Documentation/howto/dpdk.rst b/Documentation/howto/dpdk.rst
index d1e6e89..29b47b6 100644
--- a/Documentation/howto/dpdk.rst
+++ b/Documentation/howto/dpdk.rst
@@ -354,6 +354,25 @@ the `DPDK documentation
 
 Note: Not all DPDK virtual PMD drivers have been tested and verified to work.
 
+EMC Insertion Probability
+-
+By default 1 in every 100 flows are inserted into the Exact Match Cache (EMC).
+It is possible to change this insertion probability by setting the
+``emc-insert-prob`` option::
+
+$ ovs-vsctl --no-wait set Open_vSwitch . other_config:emc-insert-prob=N
+
+where:
+
+``N``
+  is a positive integer between 0 and 100 representing the percentage
+  probability of EMC insertion.
+
+If ``N`` is set to 100, an insertion will be performed for every flow. If set
+to 0, no insertions will be performed and the EMC will effectively be disabled.
+
+For more information on the EMC refer to :doc:`/intro/install/dpdk` .
+
 .. _dpdk-ovs-in-guest:
 
 OVS with DPDK Inside VMs
diff --git a/NEWS b/NEWS
index aebd99c..6fc586a 100644
--- a/NEWS
+++ b/NEWS
@@ -70,6 +70,8 @@ v2.7.0 - xx xxx 
specified.
  * Virtual DPDK Poll Mode Driver (vdev PMD) support.
  * Removed experimental tag.
+ * EMC insertion probability is reduced to 1% and is configurable via the
+   new 'other_config:emc-insert-prob' option.
- Fedora packaging:
  * A package upgrade does not automatically restart OVS service.
- ovs-vswitchd/ovs-vsctl:
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 0be5db5..5279e52 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -144,6 +144,11 @@ struct netdev_flow_key {
 #define EM_FLOW_HASH_MASK (EM_FLOW_HASH_ENTRIES - 1)
 #define EM_FLOW_HASH_SEGS 2
 
+/* Percentage probability of calling emc_insert */
+#define DEFAULT_EM_FLOW_INSERT_PROB 1
+#define DEFAULT_EM_FLOW_INSERT_MIN (UINT32_MAX /\
+(100 / DEFAULT_EM_FLOW_INSERT_PROB))
+
 struct emc_entry {
 struct dp_netdev_flow *flow;
 struct netdev_flow_key key;   /* key.hash used for emc hash value. */
@@ -254,6 +259,9 @@ struct dp_netdev {
 uint64_t last_tnl_conf_seq;
 
 struct conntrack conntrack;
+
+/* Probability of EMC insertions is a factor of 'emc_insert_min'.*/
+OVS_ALIGNED_VAR(CACHE_LINE_SIZE)atomic_uint32_t 

Re: [ovs-dev] [PATCH v6] dpif-netdev: Conditional EMC insert

[Jan Scheurich]

Thanks Ciara, 

But why have you not moved the atomic read of min into the function, too?

Jan

> -Original Message-
> From: Ciara Loftus [mailto:ciara.lof...@intel.com]
> Sent: Thursday, 09 February, 2017 16:42
> To: d...@openvswitch.org
> Cc: jan.scheur...@web.de; diproiet...@ovn.org; i.maxim...@samsung.com; Ciara 
> Loftus ; Georg Schmuecking
> 
> Subject: [PATCH v6] dpif-netdev: Conditional EMC insert
> 
> Unconditional insertion of EMC entries results in EMC thrashing at high
> numbers of parallel flows. When this occurs, the performance of the EMC
> often falls below that of the dpcls classifier, rendering the EMC
> practically useless.
> 
> Instead of unconditionally inserting entries into the EMC when a miss
> occurs, use a 1% probability of insertion. This ensures that the most
> frequent flows have the highest chance of creating an entry in the EMC,
> and the probability of thrashing the EMC is also greatly reduced.
> 
> The probability of insertion is configurable, via the
> other_config:emc-insert-prob option. For example the following command
> increases the insertion probability to 10%.
> 
> ovs-vsctl set Open_vSwitch . other_config:emc-insert-prob=10
> 
> Signed-off-by: Ciara Loftus 
> Signed-off-by: Georg Schmuecking 
> Co-authored-by: Georg Schmuecking 
> ---
> v6:
> - Refactor the code to remove duplication around calls to
>   emc_probabilistic_insert()
> v5:
> - Use percentiles for emc-insert-prob (0-100%)
> - Update docs to reflect the option not exclusive to the DPDK datapath.
> v4:
> - Added Georg to Authors file
> - Set emc-insert-prob=1 for 'PMD - stats' unit test
> - Use read_relaxed on atomic var
> - Correctly allow for 0 and 100% probababilites
> - Cache align new element in dp_netdev struct
> - Revert to default probability if invalid emc-insert-prob set
> - Allow configurability for non-DPDK case
> v3:
> - Use new dpif other_config infrastructure to tidy up how the
>   emc-insert-prob value is passed to dpif-netdev.
> v2:
> - Enable probability configurability via other_config:emc-insert-prob
>   option.
> 
>  AUTHORS.rst  |  1 +
>  Documentation/howto/dpdk.rst | 19 +
>  NEWS |  2 ++
>  lib/dpif-netdev.c| 49 
> +---
>  tests/pmd.at |  1 +
>  vswitchd/vswitch.xml | 13 
>  6 files changed, 82 insertions(+), 3 deletions(-)
> 
> diff --git a/AUTHORS.rst b/AUTHORS.rst
> index b567fcc..3382ad8 100644
> --- a/AUTHORS.rst
> +++ b/AUTHORS.rst
> @@ -382,6 +382,7 @@ Eric Lopez  elo...@nicira.com
>  Frido Roose fr.ro...@gmail.com
>  Gaetano Catalli gaetano.cata...@gmail.com
>  Gavin Remaley   gavin_rema...@selinc.com
> +Georg Schmuecking   georg.schmueck...@ericsson.com
>  George Shuklin  ama...@desunote.ru
>  Gerald Rogers   gerald.rog...@intel.com
>  Ghanem Bahribahri.gha...@gmail.com
> diff --git a/Documentation/howto/dpdk.rst b/Documentation/howto/dpdk.rst
> index d1e6e89..29b47b6 100644
> --- a/Documentation/howto/dpdk.rst
> +++ b/Documentation/howto/dpdk.rst
> @@ -354,6 +354,25 @@ the `DPDK documentation
> 
>  Note: Not all DPDK virtual PMD drivers have been tested and verified to work.
> 
> +EMC Insertion Probability
> +-
> +By default 1 in every 100 flows are inserted into the Exact Match Cache 
> (EMC).
> +It is possible to change this insertion probability by setting the
> +``emc-insert-prob`` option::
> +
> +$ ovs-vsctl --no-wait set Open_vSwitch . other_config:emc-insert-prob=N
> +
> +where:
> +
> +``N``
> +  is a positive integer between 0 and 100 representing the percentage
> +  probability of EMC insertion.
> +
> +If ``N`` is set to 100, an insertion will be performed for every flow. If set
> +to 0, no insertions will be performed and the EMC will effectively be 
> disabled.
> +
> +For more information on the EMC refer to :doc:`/intro/install/dpdk` .
> +
>  .. _dpdk-ovs-in-guest:
> 
>  OVS with DPDK Inside VMs
> diff --git a/NEWS b/NEWS
> index aebd99c..6fc586a 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -70,6 +70,8 @@ v2.7.0 - xx xxx 
> specified.
>   * Virtual DPDK Poll Mode Driver (vdev PMD) support.
>   * Removed experimental tag.
> + * EMC insertion probability is reduced to 1% and is configurable via the
> +   new 'other_config:emc-insert-prob' option.
> - Fedora packaging:
>   * A package upgrade does not automatically restart OVS service.
> - ovs-vswitchd/ovs-vsctl:
> diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
> index 0be5db5..82e81cf 100644
> --- a/lib/dpif-netdev.c
> +++ b/lib/dpif-netdev.c
> @@ -144,6 +144,11 @@ struct netdev_flow_key {
>  #define EM_FLOW_HASH_MASK 

[ovs-dev] [PATCH v4 2/2] tunneling: Avoid recirculation on datapath by computing the recirculate actions at translate time.

[Sugesh Chandran]

Openvswitch datapath recirculates packets for tunneling, i.e.
the incoming packets are encapsulated at first pass. Further actions are
applied on encapsulated packets on the second pass after recirculating.
The proposed patch compute and append the post tunnel actions at the time of
translation itself instead of recirculating at datapath. These actions are 
solely
depends on tunnel attributes so there is no need of datapath recirculation.
By avoiding the recirculation at datapath, the patch offers upto 30%
performance improvement for VxLAN tunneling in our testing.
The action execution logic is using the new CLONE action to define
the packet cloning when the actions are combined. The lenght in the CLONE
action specifies the size of nested action set.

Also fixing the test suites failures that are introduced by CLONE action in
tunneling except the ovn test case 2299.

Signed-off-by: Sugesh Chandran 
Signed-off-by: Zoltán Balogh 
Co-authored-by: Zoltán Balogh 
---
 lib/dpif-netdev.c |  18 +--
 ofproto/ofproto-dpif-xlate.c  | 271 ++
 tests/ofproto-dpif.at |  11 +-
 tests/tunnel-push-pop-ipv6.at |  10 +-
 tests/tunnel-push-pop.at  |  12 +-
 5 files changed, 152 insertions(+), 170 deletions(-)

diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 0be5db5..b2711d5 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -4557,24 +4557,8 @@ dp_execute_cb(void *aux_, struct dp_packet_batch 
*packets_,
 
 case OVS_ACTION_ATTR_TUNNEL_PUSH:
 if (*depth < MAX_RECIRC_DEPTH) {
-struct dp_packet_batch tnl_pkt;
-struct dp_packet_batch *orig_packets_ = packets_;
-int err;
-
-if (!may_steal) {
-dp_packet_batch_clone(_pkt, packets_);
-packets_ = _pkt;
-dp_packet_batch_reset_cutlen(orig_packets_);
-}
-
 dp_packet_batch_apply_cutlen(packets_);
-
-err = push_tnl_action(pmd, a, packets_);
-if (!err) {
-(*depth)++;
-dp_netdev_recirculate(pmd, packets_);
-(*depth)--;
-}
+push_tnl_action(pmd, a, packets_);
 return;
 }
 break;
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 503a347..19dffda 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -408,6 +408,10 @@ static void xlate_action_set(struct xlate_ctx *ctx);
 static void xlate_commit_actions(struct xlate_ctx *ctx);
 
 static void
+apply_nested_clone_actions(struct xlate_ctx *ctx, const struct xport *in_dev,
+  struct xport *out_dev);
+
+static void
 ctx_trigger_freeze(struct xlate_ctx *ctx)
 {
 ctx->exit = true;
@@ -3029,7 +3033,17 @@ build_tunnel_send(struct xlate_ctx *ctx, const struct 
xport *xport,
 }
 tnl_push_data.tnl_port = odp_to_u32(tunnel_odp_port);
 tnl_push_data.out_port = odp_to_u32(out_dev->odp_port);
+
+size_t push_action_size = 0;
+size_t clone_ofs = nl_msg_start_nested(ctx->odp_actions,
+   OVS_ACTION_ATTR_CLONE);
 odp_put_tnl_push_action(ctx->odp_actions, _push_data);
+push_action_size = ctx->odp_actions->size;
+apply_nested_clone_actions(ctx, xport, out_dev);
+if (ctx->odp_actions->size > push_action_size) {
+/* Update the combine action only when combined */
+nl_msg_end_nested(ctx->odp_actions, clone_ofs);
+}
 return 0;
 }
 
@@ -3070,6 +3084,129 @@ xlate_flow_is_protected(const struct xlate_ctx *ctx, 
const struct flow *flow, co
 xport_in->xbundle->protected && xport_out->xbundle->protected);
 }
 
+/* Populate and apply nested actions on 'out_dev'.
+ * The nested actions are applied on cloned packets in dp while outputting to
+ * either patch or tunnel ports.
+ * On output to a patch port, the output action will be replaced with set of
+ * nested actions on the peer patch port.
+ * Similarly on output to a tunnel port, the post nested actions on
+ * tunnel are chained up with the tunnel-push action.
+ */
+static void
+apply_nested_clone_actions(struct xlate_ctx *ctx, const struct xport *in_dev,
+  struct xport *out_dev)
+{
+struct flow *flow = >xin->flow;
+struct flow old_flow = ctx->xin->flow;
+struct flow_tnl old_flow_tnl_wc = ctx->wc->masks.tunnel;
+bool old_conntrack = ctx->conntracked;
+bool old_was_mpls = ctx->was_mpls;
+ovs_version_t old_version = ctx->xin->tables_version;
+struct ofpbuf old_stack = ctx->stack;
+union mf_subvalue new_stack[1024 / sizeof(union mf_subvalue)];
+struct ofpbuf old_action_set = ctx->action_set;
+uint64_t actset_stub[1024 / 8];
+
+ofpbuf_use_stub(>stack, new_stack, sizeof new_stack);
+ofpbuf_use_stub(>action_set, actset_stub, sizeof actset_stub);
+flow->in_port.ofp_port = 

[ovs-dev] [PATCH v4 1/2] odp-execute : Apply clone action on batch of packets instead of one by one.

[Sugesh Chandran]

Clone action is optimized by cloning a batch of packets together instead of
executing independently on every packet in a batch.

Rebased onto commit: edb417cc256e7d5f02f230867865c8cf7f26e542
 ovs-ofctl: fix memory leak reported by valgrind.

Signed-off-by: Sugesh Chandran 
Signed-off-by: Zoltán Balogh 
Co-authored-by: Zoltán Balogh 
---
 lib/odp-execute.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/lib/odp-execute.c b/lib/odp-execute.c
index 1f6812a..9cb85c1 100644
--- a/lib/odp-execute.c
+++ b/lib/odp-execute.c
@@ -537,23 +537,26 @@ odp_execute_sample(void *dp, struct dp_packet *packet, 
bool steal,
 }
 
 static void
-odp_execute_clone(void *dp, struct dp_packet *packet, bool steal,
+odp_execute_clone(void *dp, struct dp_packet_batch *batch, bool steal,
const struct nlattr *actions,
odp_execute_cb dp_execute_action)
 {
-struct dp_packet_batch pb;
-
 if (!steal) {
 /* The 'actions' may modify the packet, but the modification
  * should not propagate beyond this clone action. Make a copy
  * the packet in case we don't own the packet, so that the
  * 'actions' are only applied to the clone.  'odp_execute_actions'
  * will free the clone.  */
-packet = dp_packet_clone(packet);
-}
-dp_packet_batch_init_packet(, packet);
-odp_execute_actions(dp, , true, nl_attr_get(actions),
+struct dp_packet_batch clone_pkt_batch;
+dp_packet_batch_clone(_pkt_batch, batch);
+dp_packet_batch_reset_cutlen(batch);
+odp_execute_actions(dp, _pkt_batch, true, nl_attr_get(actions),
 nl_attr_get_size(actions), dp_execute_action);
+}
+else {
+odp_execute_actions(dp, batch, true, nl_attr_get(actions),
+nl_attr_get_size(actions), dp_execute_action);
+}
 }
 
 static bool
@@ -712,11 +715,8 @@ odp_execute_actions(void *dp, struct dp_packet_batch 
*batch, bool steal,
 }
 
 case OVS_ACTION_ATTR_CLONE:
-DP_PACKET_BATCH_FOR_EACH (packet, batch) {
-odp_execute_clone(dp, packet, steal && last_action, a,
-  dp_execute_action);
-}
-
+odp_execute_clone(dp, batch, steal && last_action, a,
+dp_execute_action);
 if (last_action) {
 /* We do not need to free the packets. odp_execute_clone() has
  * stolen them.  */
-- 
2.7.4

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v4 0/2] tunneling : Improving tunneling performance using CLONE action at tunnel push

[Sugesh Chandran]

This patch set removes the recirculation of encapsulated tunnel packets by
computing the post tunnel actions at the time of translation.The combined
nested action set are programmed in the datapath using CLONE action.

v4
- Rename the function to compute post tunnel nested function.
- Use the clone action syntax itself for the flow display.
- Use nl_msg functions for handling the nested attribute.
- Modify the CLONE action to process packets in batch than individually.
v3
- Rebase with newely clone action and use it for tunneling.
v2
- Use only single CLONE action with length to mark the tunnel combine action 
set.
- Update the datapath trace display functions to handle CLONE.
- Fixed test cases to work with CLONE action.

Sugesh Chandran (2):
  odp-execute : Apply clone action on batch of packets instead of one by
one.
  tunneling: Avoid recirculation on datapath by computing the
recirculate actions at translate time.

 lib/dpif-netdev.c |  18 +--
 lib/odp-execute.c |  24 ++--
 ofproto/ofproto-dpif-xlate.c  | 271 ++
 tests/ofproto-dpif.at |  11 +-
 tests/tunnel-push-pop-ipv6.at |  10 +-
 tests/tunnel-push-pop.at  |  12 +-
 6 files changed, 164 insertions(+), 182 deletions(-)

-- 
2.7.4

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v2 1/4] datapath: backport: vlan: Introduce helper functions to check if skb is tagged

[Eric Garver]

On Mon, Feb 06, 2017 at 08:36:48PM +0800, Yi Yang wrote:
> commit f5a7fb88e1f82542ca14ba93a1d4fa35471c60ca
> Author: Toshiaki Makita 
> Date:   Fri Mar 27 14:31:11 2015 +0900
> 
> vlan: Introduce helper functions to check if skb is tagged
> 
> Separate the two checks for single vlan and multiple vlans in
> netif_skb_features().  This allows us to move the check for multiple
> vlans to another function later.
> 
> Signed-off-by: Toshiaki Makita 
> Signed-off-by: David S. Miller 
> 
> Signed-off-by: Yi Yang 

Acked-by: Eric Garver 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v2 3/4] datapath: backport: vlan: Check for vlan ethernet types for 8021.q or 802.1ad

[Eric Garver]

On Mon, Feb 06, 2017 at 08:36:50PM +0800, Yi Yang wrote:
> commit fe19c4f971a55cea3be442d8032a5f6021702791
> Author: Eric Garver 
> Date:   Wed Sep 7 12:56:58 2016 -0400
> 
> This is to simplify using double tagged vlans. This function allows all
> valid vlan ethertypes to be checked in a single function call.
> Also replace some instances that check for both ETH_P_8021Q and
> ETH_P_8021AD.
> 
> Patch based on one originally by Thomas F Herbert.
> 
> Signed-off-by: Thomas F Herbert 
> Signed-off-by: Eric Garver 
> Acked-by: Pravin B Shelar 
> Signed-off-by: David S. Miller 
> 
> Signed-off-by: Yi Yang 
> ---
>  acinclude.m4  |  1 +
>  datapath/linux/compat/include/linux/if_vlan.h | 24 +---
>  2 files changed, 22 insertions(+), 3 deletions(-)
> 
> diff --git a/acinclude.m4 b/acinclude.m4
> index 9166da8..f219bec 100644
> --- a/acinclude.m4
> +++ b/acinclude.m4
> @@ -664,6 +664,7 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
>OVS_GREP_IFELSE([$KSRC/include/linux/if_vlan.h], [__vlan_insert_tag])
>OVS_GREP_IFELSE([$KSRC/include/linux/if_vlan.h], [vlan_get_protocol])
>OVS_GREP_IFELSE([$KSRC/include/linux/if_vlan.h], [skb_vlan_tagged])
> +  OVS_GREP_IFELSE([$KSRC/include/linux/if_vlan.h], [eth_type_vlan])
>  
>OVS_GREP_IFELSE([$KSRC/include/linux/u64_stats_sync.h], 
> [u64_stats_fetch_begin_irq])
>  
> diff --git a/datapath/linux/compat/include/linux/if_vlan.h 
> b/datapath/linux/compat/include/linux/if_vlan.h
> index c8ddef1..ff55fb8 100644
> --- a/datapath/linux/compat/include/linux/if_vlan.h
> +++ b/datapath/linux/compat/include/linux/if_vlan.h
> @@ -100,6 +100,25 @@ static inline struct sk_buff 
> *rpl___vlan_hwaccel_put_tag(struct sk_buff *skb,
>  #define __vlan_hwaccel_put_tag rpl___vlan_hwaccel_put_tag
>  #endif
>  
> +#ifndef HAVE_ETH_TYPE_VLAN
> +/**
> + * eth_type_vlan - check for valid vlan ether type.
> + * @ethertype: ether type to check
> + *
> + * Returns true if the ether type is a vlan ether type.
> + */
> +static inline bool eth_type_vlan(__be16 ethertype)
> +{
> + switch (ethertype) {
> + case htons(ETH_P_8021Q):
> + case htons(ETH_P_8021AD):
> + return true;
> + default:
> + return false;
> + }
> +}
> +#endif
> +
>  /* All of these were introduced in a single commit preceding 2.6.33, so
>   * presumably all of them or none of them are present. */
>  #ifndef VLAN_PRIO_MASK
> @@ -188,7 +207,7 @@ static inline __be16 __vlan_get_protocol(struct sk_buff 
> *skb, __be16 type,
>* present at mac_len - VLAN_HLEN (if mac_len > 0), or at
>* ETH_HLEN otherwise
>*/
> - if (type == htons(ETH_P_8021Q) || type == htons(ETH_P_8021AD)) {
> + if (eth_type_vlan(type)) {
>   if (vlan_depth) {
>   if (WARN_ON(vlan_depth < VLAN_HLEN))
>   return 0;
> @@ -206,8 +225,7 @@ static inline __be16 __vlan_get_protocol(struct sk_buff 
> *skb, __be16 type,
>   vh = (struct vlan_hdr *)(skb->data + vlan_depth);
>   type = vh->h_vlan_encapsulated_proto;
>   vlan_depth += VLAN_HLEN;
> - } while (type == htons(ETH_P_8021Q) ||
> -  type == htons(ETH_P_8021AD));
> + } while (eth_type_vlan(type));
>   }
>  
>   if (depth)

I think you can also take the hunks for skb_vlan_tagged() and
skb_vlan_tagged_multi() since you add them in the previous patch.

__vlan_get_tag() isn't in the OVS datapath, so that hunk can be omitted.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] rhel: Fix dpdk-devel version and dependencies in fedora packager

[Timothy Redaelli]

Now dpdk-devel >= 16.11 is needed and also libpcap-devel numactl-devel

Tested on mock with rawhide chroot and Fedora 23 vagrant machine by using the
rawhide dpdk and dpdk-devel packages

Signed-off-by: Timothy Redaelli 
---
 rhel/openvswitch-fedora.spec.in | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/rhel/openvswitch-fedora.spec.in b/rhel/openvswitch-fedora.spec.in
index 1173ade..b395613 100644
--- a/rhel/openvswitch-fedora.spec.in
+++ b/rhel/openvswitch-fedora.spec.in
@@ -63,7 +63,8 @@ BuildRequires: procps-ng
 BuildRequires: libcap-ng libcap-ng-devel
 %endif
 %if %{with dpdk}
-BuildRequires: dpdk-devel >= 2.2.0
+BuildRequires: libpcap-devel numactl-devel
+BuildRequires: dpdk-devel >= 16.11
 Provides: %{name}-dpdk = %{version}-%{release}
 %endif
 
-- 
2.9.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] vagrant: Use official boxes for Fedora and Centos

[Timothy Redaelli]

Change CentOS version to last 7 (7.3 at the moment)
since old kernel-devel version is no longer available

Add net-tools to CentOS since netstat is needed for some tests

Signed-off-by: Timothy Redaelli 
---
 Vagrantfile | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/Vagrantfile b/Vagrantfile
index ef25c77..3937f14 100644
--- a/Vagrantfile
+++ b/Vagrantfile
@@ -36,7 +36,7 @@ yum -y install autoconf automake openssl-devel libtool \
python-twisted-core python-zope-interface \
desktop-file-utils groff graphviz rpmdevtools nc curl \
wget python-six pyftpdlib checkpolicy selinux-policy-devel \
-   libcap-ng-devel kernel-devel-`uname -r` ethtool
+   libcap-ng-devel kernel-devel-`uname -r` ethtool net-tools
 SCRIPT
 
 $configure_ovs = 

Re: [ovs-dev] [PATCH v4] dpif-netdev: Conditional EMC insert

[Jan Scheurich]

I'd suggest not to duplicate the code around the calls to 
emc_probabilistic_insert() but move it into the function itself, passing pmd 
instead of pmd->flow_cache as first argument.

Jan

> @@ -4194,7 +4231,15 @@ handle_packet_upcall(struct dp_netdev_pmd_thread *pmd, 
> struct dp_packet *packet,
>  }
>  ovs_mutex_unlock(>flow_mutex);
> 
> -emc_insert(>flow_cache, key, netdev_flow);
> +uint32_t min;
> +atomic_read_relaxed(>dp->emc_insert_min, );
> +#ifdef DPDK_NETDEV
> +emc_probabilistic_insert(>flow_cache, key, netdev_flow,
> + pmd->last_cycles, min);
> +#else
> +emc_probabilistic_insert(>flow_cache, key, netdev_flow,
> + random_uint32(), min);
> +#endif
>  }
>  }
> 
> @@ -4288,7 +4333,15 @@ fast_path_processing(struct dp_netdev_pmd_thread *pmd,
> 
>  flow = dp_netdev_flow_cast(rules[i]);
> 
> -emc_insert(flow_cache, [i], flow);
> +uint32_t min;
> +atomic_read_relaxed(>dp->emc_insert_min, );
> +#ifdef DPDK_NETDEV
> +emc_probabilistic_insert(flow_cache, [i], flow,
> + pmd->last_cycles, min);
> +#else
> +emc_probabilistic_insert(flow_cache, [i], flow,
> + random_uint32(), min);
> +#endif
>  dp_netdev_queue_batches(packet, flow, [i].mf, batches, 
> n_batches);
>  }
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH branch-2.7 1/1] datapath: maintain correct checksum state in conntrack actions.

[Lance Richardson]

> From: "Joe Stringer" 
> To: d...@openvswitch.org
> Cc: "Lance Richardson" 
> Sent: Wednesday, February 8, 2017 8:14:08 PM
> Subject: [PATCH branch-2.7 1/1] datapath: maintain correct checksum state in 
> conntrack actions.
> 
> Upstream commit:
> openvswitch: maintain correct checksum state in conntrack actions
> 
> When executing conntrack actions on skbuffs with checksum mode
> CHECKSUM_COMPLETE, the checksum must be updated to account for
> header pushes and pulls. Otherwise we get "hw csum failure"
> logs similar to this (ICMP packet received on geneve tunnel
> via ixgbe NIC):
> 
> [  405.740065] genev_sys_6081: hw csum failure
> [  405.740106] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G  I
> 4.10.0-rc3+ #1
> [  405.740108] Call Trace:
> [  405.740110]  
> [  405.740113]  dump_stack+0x63/0x87
> [  405.740116]  netdev_rx_csum_fault+0x3a/0x40
> [  405.740118]  __skb_checksum_complete+0xcf/0xe0
> [  405.740120]  nf_ip_checksum+0xc8/0xf0
> [  405.740124]  icmp_error+0x1de/0x351 [nf_conntrack_ipv4]
> [  405.740132]  nf_conntrack_in+0xe1/0x550 [nf_conntrack]
> [  405.740137]  ? find_bucket.isra.2+0x62/0x70 [openvswitch]
> [  405.740143]  __ovs_ct_lookup+0x95/0x980 [openvswitch]
> [  405.740145]  ? netif_rx_internal+0x44/0x110
> [  405.740149]  ovs_ct_execute+0x147/0x4b0 [openvswitch]
> [  405.740153]  do_execute_actions+0x22e/0xa70 [openvswitch]
> [  405.740157]  ovs_execute_actions+0x40/0x120 [openvswitch]
> [  405.740161]  ovs_dp_process_packet+0x84/0x120 [openvswitch]
> [  405.740166]  ovs_vport_receive+0x73/0xd0 [openvswitch]
> [  405.740168]  ? udp_rcv+0x1a/0x20
> [  405.740170]  ? ip_local_deliver_finish+0x93/0x1e0
> [  405.740172]  ? ip_local_deliver+0x6f/0xe0
> [  405.740174]  ? ip_rcv_finish+0x3a0/0x3a0
> [  405.740176]  ? ip_rcv_finish+0xdb/0x3a0
> [  405.740177]  ? ip_rcv+0x2a7/0x400
> [  405.740180]  ? __netif_receive_skb_core+0x970/0xa00
> [  405.740185]  netdev_frame_hook+0xd3/0x160 [openvswitch]
> [  405.740187]  __netif_receive_skb_core+0x1dc/0xa00
> [  405.740194]  ? ixgbe_clean_rx_irq+0x46d/0xa20 [ixgbe]
> [  405.740197]  __netif_receive_skb+0x18/0x60
> [  405.740199]  netif_receive_skb_internal+0x40/0xb0
> [  405.740201]  napi_gro_receive+0xcd/0x120
> [  405.740204]  gro_cell_poll+0x57/0x80 [geneve]
> [  405.740206]  net_rx_action+0x260/0x3c0
> [  405.740209]  __do_softirq+0xc9/0x28c
> [  405.740211]  irq_exit+0xd9/0xf0
> [  405.740213]  do_IRQ+0x51/0xd0
> [  405.740215]  common_interrupt+0x93/0x93
> 
> Fixes: 7f8a436eaa2c ("openvswitch: Add conntrack action")
> Signed-off-by: Lance Richardson 
> Acked-by: Pravin B Shelar 
> Signed-off-by: David S. Miller 
> 
> Upstream: 75f01a4c9cc2 ("openvswitch: maintain correct checksum state in
> conntrack actions")
> Signed-off-by: Joe Stringer 
> ---
> CC: Lance Richardson 
> ---
>  datapath/conntrack.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/datapath/conntrack.c b/datapath/conntrack.c
> index 3c51ce6bcfa8..a0c54438728e 100644
> --- a/datapath/conntrack.c
> +++ b/datapath/conntrack.c
> @@ -555,7 +555,7 @@ static int ovs_ct_nat_execute(struct sk_buff *skb, struct
> nf_conn *ct,
>   int hooknum, nh_off, err = NF_ACCEPT;
>  
>   nh_off = skb_network_offset(skb);
> - skb_pull(skb, nh_off);
> + skb_pull_rcsum(skb, nh_off);
>  
>   /* See HOOK2MANIP(). */
>   if (maniptype == NF_NAT_MANIP_SRC)
> @@ -620,6 +620,7 @@ static int ovs_ct_nat_execute(struct sk_buff *skb, struct
> nf_conn *ct,
>   err = nf_nat_packet(ct, ctinfo, hooknum, skb);
>  push:
>   skb_push(skb, nh_off);
> + skb_postpush_rcsum(skb, skb->data, nh_off);
>  
>   return err;
>  }
> @@ -931,7 +932,7 @@ int ovs_ct_execute(struct net *net, struct sk_buff *skb,
>  
>   /* The conntrack module expects to be working at L3. */
>   nh_ofs = skb_network_offset(skb);
> - skb_pull(skb, nh_ofs);
> + skb_pull_rcsum(skb, nh_ofs);
>  
>   if (key->ip.frag != OVS_FRAG_TYPE_NONE) {
>   err = handle_fragments(net, key, info->zone.id, skb);
> @@ -945,6 +946,7 @@ int ovs_ct_execute(struct net *net, struct sk_buff *skb,
>   err = ovs_ct_lookup(net, key, info, skb);
>  
>   skb_push(skb, nh_ofs);
> + skb_postpush_rcsum(skb, skb->data, nh_ofs);
>   if (err)
>   kfree_skb(skb);
>   return err;
> --
> 2.11.0
> 
> 

Acked-by: Lance Richardson 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v5] dpif-netdev: Conditional EMC insert

[Ciara Loftus]

Unconditional insertion of EMC entries results in EMC thrashing at high
numbers of parallel flows. When this occurs, the performance of the EMC
often falls below that of the dpcls classifier, rendering the EMC
practically useless.

Instead of unconditionally inserting entries into the EMC when a miss
occurs, use a 1% probability of insertion. This ensures that the most
frequent flows have the highest chance of creating an entry in the EMC,
and the probability of thrashing the EMC is also greatly reduced.

The probability of insertion is configurable, via the
other_config:emc-insert-prob option. For example the following command
increases the insertion probability to 10%.

ovs-vsctl set Open_vSwitch . other_config:emc-insert-prob=10

Signed-off-by: Ciara Loftus 
Signed-off-by: Georg Schmuecking 
Co-authored-by: Georg Schmuecking 
---
v5:
- Use percentiles for emc-insert-prob (0-100%)
- Update docs to reflect the option not exclusive to the DPDK datapath.
v4:
- Added Georg to Authors file
- Set emc-insert-prob=1 for 'PMD - stats' unit test
- Use read_relaxed on atomic var
- Correctly allow for 0 and 100% probababilites
- Cache align new element in dp_netdev struct
- Revert to default probability if invalid emc-insert-prob set
- Allow configurability for non-DPDK case
v3:
- Use new dpif other_config infrastructure to tidy up how the
  emc-insert-prob value is passed to dpif-netdev.
v2:
- Enable probability configurability via other_config:emc-insert-prob
  option.

 AUTHORS.rst  |  1 +
 Documentation/howto/dpdk.rst | 19 +++
 NEWS |  2 ++
 lib/dpif-netdev.c| 57 ++--
 tests/pmd.at |  1 +
 vswitchd/vswitch.xml | 13 ++
 6 files changed, 91 insertions(+), 2 deletions(-)

diff --git a/AUTHORS.rst b/AUTHORS.rst
index b567fcc..3382ad8 100644
--- a/AUTHORS.rst
+++ b/AUTHORS.rst
@@ -382,6 +382,7 @@ Eric Lopez  elo...@nicira.com
 Frido Roose fr.ro...@gmail.com
 Gaetano Catalli gaetano.cata...@gmail.com
 Gavin Remaley   gavin_rema...@selinc.com
+Georg Schmuecking   georg.schmueck...@ericsson.com
 George Shuklin  ama...@desunote.ru
 Gerald Rogers   gerald.rog...@intel.com
 Ghanem Bahribahri.gha...@gmail.com
diff --git a/Documentation/howto/dpdk.rst b/Documentation/howto/dpdk.rst
index d1e6e89..29b47b6 100644
--- a/Documentation/howto/dpdk.rst
+++ b/Documentation/howto/dpdk.rst
@@ -354,6 +354,25 @@ the `DPDK documentation
 
 Note: Not all DPDK virtual PMD drivers have been tested and verified to work.
 
+EMC Insertion Probability
+-
+By default 1 in every 100 flows are inserted into the Exact Match Cache (EMC).
+It is possible to change this insertion probability by setting the
+``emc-insert-prob`` option::
+
+$ ovs-vsctl --no-wait set Open_vSwitch . other_config:emc-insert-prob=N
+
+where:
+
+``N``
+  is a positive integer between 0 and 100 representing the percentage
+  probability of EMC insertion.
+
+If ``N`` is set to 100, an insertion will be performed for every flow. If set
+to 0, no insertions will be performed and the EMC will effectively be disabled.
+
+For more information on the EMC refer to :doc:`/intro/install/dpdk` .
+
 .. _dpdk-ovs-in-guest:
 
 OVS with DPDK Inside VMs
diff --git a/NEWS b/NEWS
index aebd99c..6fc586a 100644
--- a/NEWS
+++ b/NEWS
@@ -70,6 +70,8 @@ v2.7.0 - xx xxx 
specified.
  * Virtual DPDK Poll Mode Driver (vdev PMD) support.
  * Removed experimental tag.
+ * EMC insertion probability is reduced to 1% and is configurable via the
+   new 'other_config:emc-insert-prob' option.
- Fedora packaging:
  * A package upgrade does not automatically restart OVS service.
- ovs-vswitchd/ovs-vsctl:
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 0be5db5..488753d 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -144,6 +144,11 @@ struct netdev_flow_key {
 #define EM_FLOW_HASH_MASK (EM_FLOW_HASH_ENTRIES - 1)
 #define EM_FLOW_HASH_SEGS 2
 
+/* Percentage probability of calling emc_insert */
+#define DEFAULT_EM_FLOW_INSERT_PROB 1
+#define DEFAULT_EM_FLOW_INSERT_MIN (UINT32_MAX /\
+(100 / DEFAULT_EM_FLOW_INSERT_PROB))
+
 struct emc_entry {
 struct dp_netdev_flow *flow;
 struct netdev_flow_key key;   /* key.hash used for emc hash value. */
@@ -254,6 +259,9 @@ struct dp_netdev {
 uint64_t last_tnl_conf_seq;
 
 struct conntrack conntrack;
+
+/* Probability of EMC insertions is a factor of 'emc_insert_min'.*/
+OVS_ALIGNED_VAR(CACHE_LINE_SIZE)atomic_uint32_t emc_insert_min;
 };
 
 static struct dp_netdev_port *dp_netdev_lookup_port(const struct dp_netdev *dp,
@@ -1066,6 +1074,8 @@ 

Re: [ovs-dev] [RFC PATCH v2] Pipeline packet processing in OVS using FVL flow director.

[Mark Bloch]

Hi Sugesh,

First of all, thanks for the respin of this patch.

The overall idea of using HW classification abilities to do offloads
is something we would also like to tackle, so thank you for being first!  

I have a few comments, please see inline.

On 2/6/2017 7:39 PM, Sugesh Chandran wrote:
> The patch uses a pipeline model of packet processing in dpif-netdev.
> Packets are processed by either normal or hardware pipeline based on flow-
> director ID on the packet. The extendable model allows to enable any type
> of partial offloads(Packet types, flow director) in a need basis.
> The patch improved VxLAN decapsulation performance by ~62% .As a caveat, the
> default software path performance is reduced by ~6-7% due to the
> pipeline handling overhead.
> 
> Following major changes are introduced by this commit.
> 
> 1) Added a netdev specific pipeline selection logic on packet reception.
> 2) Every packet carries a 64 bit pipeline metadata over the lifetime of packet
> in OVS.
> 3) Selective miniflow extract logic is introduced for pipeline based miniflow
> extract.
> 4) Flow insert logic is modified to replace the default s/w rules of vxlan
> tunneling with (h/w + s/w) rules.
> 5) Action logic is modified to perform the light-weight tunnel pop for the
> hardware pipeline.
> 
> TODO::
> 1) Flow insertions are handled by the PMD threads at the moment. Its necessary
> to define a handler thread to install hw+s/w flows to avoid blocking PMD
> threads for longer period.
> 2) Hardware flow deletion is not implemented in this patch. Can add when the
> flow insert approach is finalized.
> 3) hardware specific rules are populated only at emc level. dp_classifier also
> need to be populated accordingly.
> 
> Signed-off-by: Sugesh Chandran 
> 
> ---
> v2
> Rebased to latest OVS source tree
> ---
>   include/openvswitch/flow.h|   9 +-
>   include/openvswitch/packets.h |  15 ++-
>   lib/automake.mk   |   8 +-
>   lib/dpdk-i40e-ofld.c  | 207 
>   lib/dpdk-i40e-ofld.h  |  73 +
>   lib/dpif-netdev.c | 237 
> ++
>   lib/flow.c|  71 +++--
>   lib/hw-pipeline.c |  75 +
>   lib/hw-pipeline.h |  52 +
>   lib/match.c   |   2 +-
>   lib/netdev-bsd.c  |   1 +
>   lib/netdev-dpdk.c |  34 +-
>   lib/netdev-dummy.c|   1 +
>   lib/netdev-linux.c|   1 +
>   lib/netdev-native-tnl.c   |  42 
>   lib/netdev-native-tnl.h   |   2 +-
>   lib/netdev-provider.h |   6 ++
>   lib/netdev-vport.c|   3 +-
>   lib/nx-match.c|   2 +-
>   lib/odp-util.h|   2 +-
>   lib/ofp-util.c|   2 +-
>   lib/packets.h |   8 ++
>   ofproto/ofproto-dpif-rid.h|   2 +-
>   ofproto/ofproto-dpif-xlate.c  |   2 +-
>   24 files changed, 801 insertions(+), 56 deletions(-)
>   create mode 100644 lib/dpdk-i40e-ofld.c
>   create mode 100644 lib/dpdk-i40e-ofld.h
>   create mode 100644 lib/hw-pipeline.c
>   create mode 100644 lib/hw-pipeline.h
> 
> diff --git a/include/openvswitch/flow.h b/include/openvswitch/flow.h
> index df80dfe..3639fc0 100644
> --- a/include/openvswitch/flow.h
> +++ b/include/openvswitch/flow.h
> @@ -23,7 +23,7 @@
>   /* This sequence number should be incremented whenever anything involving 
> flows
>* or the wildcarding of flows changes.  This will cause build assertion
>* failures in places which likely need to be updated. */
> -#define FLOW_WC_SEQ 36
> +#define FLOW_WC_SEQ 37
> 
>   /* Number of Open vSwitch extension 32-bit registers. */
>   #define FLOW_N_REGS 16
> @@ -99,6 +99,9 @@ struct flow {
>   uint32_t conj_id;   /* Conjunction ID. */
>   ofp_port_t actset_output;   /* Output port in action set. */
> 
> +uint16_t pipeline_id;
> +uint16_t pipeline_state;
> +uint8_t pad0[4]; /* Pad to make pipeline 64 bit */
>   /* L2, Order the same as in the Ethernet header! (64-bit aligned) */
>   struct eth_addr dl_dst; /* Ethernet destination address. */
>   struct eth_addr dl_src; /* Ethernet source address. */
> @@ -135,8 +138,8 @@ BUILD_ASSERT_DECL(sizeof(struct flow_tnl) % 
> sizeof(uint64_t) 
> == 0);
> 
>   /* Remember to update FLOW_WC_SEQ when changing 'struct flow'. */
>   BUILD_ASSERT_DECL(offsetof(struct flow, igmp_group_ip4) + sizeof(uint32_t)
> -  == sizeof(struct flow_tnl) + 248
> -  && FLOW_WC_SEQ == 36);
> +  == sizeof(struct flow_tnl) + 256
> +  && FLOW_WC_SEQ == 37);
> 
>   /* Incremental points at which flow classification may be performed in
>* segments.
> diff --git a/include/openvswitch/packets.h b/include/openvswitch/packets.h
> index 5d97309..26fbc87 100644
> --- a/include/openvswitch/packets.h
> +++ 

Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs

[Yang, Yi Y]

Jan, I'm ok, I will rebase those patches once ovs maintainers merge your 
patches first. In my patches, I added vxlan-gpe user space support, that needs 
those three user space patches, that is why I included those three user space 
patches in my patch set.

I don't know what order ovs maintainers will merge them in. I can only focus on 
userspace support for vxlan-gpe if ovs maintainers really merge your patches 
first.

-Original Message-
From: Jan Scheurich [mailto:jan.scheur...@ericsson.com] 
Sent: Thursday, February 9, 2017 5:50 PM
To: Yang, Yi Y ; Joe Stringer ; Jiri Benc 
(jb...@redhat.com) ; Eric Garver 
Cc: d...@openvswitch.org; Jarno Rajahalme (ja...@ovn.org) 
Subject: RE: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs

Hi Yi,

I very much doubt that it makes sense to first merge the obsolete user-space 
patches and then override them with the target version. 

Jarno and Joe have in principle agreed to merge the new user-space patches 
independently of the backport of the kernel datapath patches. So there is no 
dependency in this direction.

If it is not possible to merge the kernel datapath back-ports without test 
cases, then I think the datapath merge should wait for the merge of the new 
user-space patches and then add end-to-end test cases for the kernel datapath 
as well.

But perhaps such end-to-end tests are not strictly necessary. It appears to me 
that Jiri's L3 tunneling datapath patches were merged into net-next without 
such test cases (just based on code review). So why not in OVS tree?

We can then add end-to-end kernel datapath tests when the Eric's outstanding 
user-space patches for rtnetlink and compat tunnel configuration for L3 tunnels 
are added.

BR, Jan


> -Original Message-
> From: Yang, Yi Y [mailto:yi.y.y...@intel.com]
> Sent: Wednesday, 08 February, 2017 06:31
> To: Jan Scheurich ; Joe Stringer 
> ; Jiri Benc (jb...@redhat.com) ; Eric 
> Garver 
> Cc: d...@openvswitch.org
> Subject: RE: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset 
> to ovs
> 
> I'll check how we can rebase your changes against those three patches 
> on top of my patches, our goals are same, that is to merge your 
> changes and this patch set to ovs. I don't know what order Joe will merge 
> them in. Obviously one patch set can't depend on another one which isn't 
> nailed down to merge or not.
> 
> Jan, let us have a sync by lync meeting.
> 
> -Original Message-
> From: Jan Scheurich [mailto:jan.scheur...@ericsson.com]
> Sent: Wednesday, February 8, 2017 7:19 AM
> To: Joe Stringer ; Yang, Yi Y ; Jiri 
> Benc (jb...@redhat.com) ; Eric Garver 
> Cc: d...@openvswitch.org
> Subject: RE: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset 
> to ovs
> 
> Hi Yi,
> 
> Both Joe and Jarno have indicated there are no principle problems 
> merging our self-contained user-space patches for L3 tunneling. May I 
> suggest that you (together with Jiri and Eric) focus on the datapath 
> back-ports and the user-space patches on top needed to configure L3 tunnels 
> in the net-next and OVS tree kernel module.
> 
> /Jan
> 
> > -Original Message-
> > From: Joe Stringer [mailto:j...@ovn.org]
> > Sent: Tuesday, 07 February, 2017 18:55
> > To: Yang, Yi Y 
> > Cc: Jan Scheurich ; d...@openvswitch.org
> > Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset 
> > to ovs
> >
> > On 7 February 2017 at 05:28, Yang, Yi Y  wrote:
> > > Jan, I know that, but per Joe's comments, it seems he won't merge your 
> > > patch set unless the part in kernel side is merged before them.
> > It can't work without these three patches.
> >
> > I have primarily expressed concern about missing kernel patch 
> > backports due to inconsistent backporting order. If Jan's series is 
> > decoupled and still builds OK, tests OK, passes review, etc by 
> > itself then I'm not sure I understand the dependency on the kernel patches.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v4] dpif-netdev: Conditional EMC insert

[Ilya Maximets]

Hi, Ciara.

> +EMC Insertion Probability
> +-
> +By default 1 in every 100 flows are inserted into the Exact Match Cache 
> (EMC).
> +It is possible to change this insertion probability by setting the
> +``emc-insert-prob`` option::
> +
> +$ ovs-vsctl --no-wait set Open_vSwitch . other_config:emc-insert-prob=N
> +
> +where:
> +
> +``N``
> +  is a positive integer between 0 and 4294967295 (maximum unsigned 32bit 
> int).
> +
> +If ``N`` is set to 1, an insertion will be performed for every flow. The 
> lower
> +the value of ``emc-insert-prob`` the higher the probability of insertion,
> +except for the value 0 which will result in no insertions being performed and
> +thus essentially disabling the EMC.

I totally don't understand why 'N' is an integer between 0 and 4294967295.
Why we can't just use 0-100% for that config?

Probability in math is a value between 0 and 1. We can use an integer values
from 0 to 100 in percents. IMHO, that strange configuration kind of misleading
because 'emc-insert-prob' reads as 'emc-insert-probability' but means something
completely different. Also, does all of this values from 0 to 4294967295 are 
useful?

What do you think?

Best regards, Ilya Maximets.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] compat: Remove rpl_dev_queue_xmit() backport.

[Simon Horman]

Hi Joe,

On Wed, Feb 08, 2017 at 04:50:36PM -0800, Joe Stringer wrote:
> The MPLS portions of this were inadvertently broken in v2.4 due to
> 433637881ca5 ("datapath: define compat __skb_gso_segment()") which
> inverts the supports_mpls_gso() logic, then when rpl_dev_queue_xmit()
> backport dropped its VLAN portion in v2.6, the whole function became a
> no-op - since b63bf2488209 ("datapath: remove VLAN compat code from GSO").
> 
> Apparently the MPLS side of this code never worked in a released version
> of OVS and no-one noticed, so remove it.
> 
> Signed-off-by: Joe Stringer 
> ---
> CC: Simon Horman 
> 
> Simon, I'm not sure what the repercussions are of this but by my reading
> of the code the extra skb_gso_segment compat code here is never invoked
> anyway so I figure we can just drop it. Looks like it might've been
> fine when originally submitted, but by the time v2.4 came out it was
> already nerfed >.<
>
> That said, if we just need to fix the version check to get it working
> again then that's an option.

True. I'm pretty sure I exercised the code in question at some point so I
think it ought to work modulo being disabled. But of course some testing
would be required.  Probably this would be worth doing as unexpected GSO
failures are somewhat hard to track down IMHO.  That said, I don't feel
strongly about this given that it only affects what by now are rather old
kernels and no one seems to have reported a problem.

Do you have any view on how much longer kernels older than v3.19 will be
supported by OvS?

> Also, I see that the upstream commit
> 48d2ab609b6b ("net: mpls: Fixups for GSO") will further change the way
> that OVS deals with MPLS GSO, so perhaps we'll actually need to bring
> back a backport for handling those cases, when that patch is backported
> to the OVS tree.

Yes, it seems likely that OvS would need some compatibility code to handle
that change - and IIRC some related changes to catch all the corner cases.

> ---
>  datapath/linux/compat/gso.c | 91 
> -
>  datapath/linux/compat/include/linux/netdevice.h |  5 --
>  2 files changed, 96 deletions(-)
> 
> diff --git a/datapath/linux/compat/gso.c b/datapath/linux/compat/gso.c
> index 48a56b9f5d5f..2638f1114ede 100644
> --- a/datapath/linux/compat/gso.c
> +++ b/datapath/linux/compat/gso.c
> @@ -41,97 +41,6 @@
>  
>  #include "gso.h"
>  
> -#ifdef OVS_USE_COMPAT_GSO_SEGMENTATION
> -/* Strictly this is not needed and will be optimised out
> - * as this code is guarded by if LINUX_VERSION_CODE < KERNEL_VERSION(3,19,0).
> - * It is here to make things explicit should the compatibility
> - * code be extended in some way prior extending its life-span
> - * beyond v3.19.
> - */
> -static bool supports_mpls_gso(void)
> -{
> -/* MPLS GSO was introduced in v3.11, however it was not correctly
> - * activated using mpls_features until v3.19. */
> -#ifdef OVS_USE_COMPAT_GSO_SEGMENTATION
> - return true;
> -#else
> - return false;
> -#endif
> -}
> -
> -int rpl_dev_queue_xmit(struct sk_buff *skb)
> -{
> -#undef dev_queue_xmit
> - int err = -ENOMEM;
> - bool mpls;
> -
> - mpls = false;
> -
> - /* Avoid traversing any VLAN tags that are present to determine if
> -  * the ethtype is MPLS. Instead compare the mac_len (end of L2) and
> -  * skb_network_offset() (beginning of L3) whose inequality will
> -  * indicate the presence of an MPLS label stack. */
> - if (skb->mac_len != skb_network_offset(skb) && !supports_mpls_gso())
> - mpls = true;
> -
> - if (mpls) {
> - int features;
> -
> - features = netif_skb_features(skb);
> -
> - /* As of v3.11 the kernel provides an mpls_features field in
> -  * struct net_device which allows devices to advertise which
> -  * features its supports for MPLS. This value defaults to
> -  * NETIF_F_SG and as of v3.19.
> -  *
> -  * This compatibility code is intended for kernels older
> -  * than v3.19 that do not support MPLS GSO and do not
> -  * use mpls_features. Thus this code uses NETIF_F_SG
> -  * directly in place of mpls_features.
> -  */
> - if (mpls)
> - features &= NETIF_F_SG;
> -
> - if (netif_needs_gso(skb, features)) {
> - struct sk_buff *nskb;
> -
> - nskb = skb_gso_segment(skb, features);
> - if (!nskb) {
> - if (unlikely(skb_cloned(skb) &&
> - pskb_expand_head(skb, 0, 0, GFP_ATOMIC)))
> - goto drop;
> -
> - skb_shinfo(skb)->gso_type &= ~SKB_GSO_DODGY;
> - goto xmit;
> - }
> -
> - if (IS_ERR(nskb)) {
> - err = 

Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs

[Jan Scheurich]

Hi Yi,

I very much doubt that it makes sense to first merge the obsolete user-space 
patches and then override them with the target version. 

Jarno and Joe have in principle agreed to merge the new user-space patches 
independently of the backport of the kernel datapath patches. So there is no 
dependency in this direction.

If it is not possible to merge the kernel datapath back-ports without test 
cases, then I think the datapath merge should wait for the merge of the new 
user-space patches and then add end-to-end test cases for the kernel datapath 
as well.

But perhaps such end-to-end tests are not strictly necessary. It appears to me 
that Jiri's L3 tunneling datapath patches were merged into net-next without 
such test cases (just based on code review). So why not in OVS tree?

We can then add end-to-end kernel datapath tests when the Eric's outstanding 
user-space patches for rtnetlink and compat tunnel configuration for L3 tunnels 
are added.

BR, Jan


> -Original Message-
> From: Yang, Yi Y [mailto:yi.y.y...@intel.com]
> Sent: Wednesday, 08 February, 2017 06:31
> To: Jan Scheurich ; Joe Stringer ; 
> Jiri Benc (jb...@redhat.com) ; Eric
> Garver 
> Cc: d...@openvswitch.org
> Subject: RE: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs
> 
> I'll check how we can rebase your changes against those three patches on top 
> of my patches, our goals are same, that is to merge your
> changes and this patch set to ovs. I don't know what order Joe will merge 
> them in. Obviously one patch set can't depend on another one
> which isn't nailed down to merge or not.
> 
> Jan, let us have a sync by lync meeting.
> 
> -Original Message-
> From: Jan Scheurich [mailto:jan.scheur...@ericsson.com]
> Sent: Wednesday, February 8, 2017 7:19 AM
> To: Joe Stringer ; Yang, Yi Y ; Jiri Benc 
> (jb...@redhat.com) ; Eric Garver
> 
> Cc: d...@openvswitch.org
> Subject: RE: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs
> 
> Hi Yi,
> 
> Both Joe and Jarno have indicated there are no principle problems merging our 
> self-contained user-space patches for L3 tunneling. May I
> suggest that you (together with Jiri and Eric) focus on the datapath 
> back-ports and the user-space patches on top needed to configure L3
> tunnels in the net-next and OVS tree kernel module.
> 
> /Jan
> 
> > -Original Message-
> > From: Joe Stringer [mailto:j...@ovn.org]
> > Sent: Tuesday, 07 February, 2017 18:55
> > To: Yang, Yi Y 
> > Cc: Jan Scheurich ; d...@openvswitch.org
> > Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset
> > to ovs
> >
> > On 7 February 2017 at 05:28, Yang, Yi Y  wrote:
> > > Jan, I know that, but per Joe's comments, it seems he won't merge your 
> > > patch set unless the part in kernel side is merged before them.
> > It can't work without these three patches.
> >
> > I have primarily expressed concern about missing kernel patch
> > backports due to inconsistent backporting order. If Jan's series is
> > decoupled and still builds OK, tests OK, passes review, etc by itself
> > then I'm not sure I understand the dependency on the kernel patches.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v4] dpif-netdev: Conditional EMC insert

[Ciara Loftus]

Unconditional insertion of EMC entries results in EMC thrashing at high
numbers of parallel flows. When this occurs, the performance of the EMC
often falls below that of the dpcls classifier, rendering the EMC
practically useless.

Instead of unconditionally inserting entries into the EMC when a miss
occurs, use a 1% probability of insertion. This ensures that the most
frequent flows have the highest chance of creating an entry in the EMC,
and the probability of thrashing the EMC is also greatly reduced.

The probability of insertion is configurable, via the
other_config:emc-insert-prob option. For example the following command
increases the insertion probability to 1/10 ie. 10%.

ovs-vsctl set Open_vSwitch . other_config:emc-insert-prob=10

Signed-off-by: Ciara Loftus 
Signed-off-by: Georg Schmuecking 
Co-authored-by: Georg Schmuecking 
---
v4:
- Added Georg to Authors file
- Set emc-insert-prob=1 for 'PMD - stats' unit test
- Use read_relaxed on atomic var
- Correctly allow for 0 and 100% probababilites
- Cache align new element in dp_netdev struct
- Revert to default probability if invalid emc-insert-prob set
- Allow configurability for non-DPDK case
v3:
- Use new dpif other_config infrastructure to tidy up how the
  emc-insert-prob value is passed to dpif-netdev.
v2:
- Enable probability configurability via other_config:emc-insert-prob
  option.

 AUTHORS.rst  |  1 +
 Documentation/howto/dpdk.rst | 20 
 NEWS |  2 ++
 lib/dpif-netdev.c| 57 ++--
 tests/pmd.at |  1 +
 vswitchd/vswitch.xml | 16 +
 6 files changed, 95 insertions(+), 2 deletions(-)

diff --git a/AUTHORS.rst b/AUTHORS.rst
index b567fcc..3382ad8 100644
--- a/AUTHORS.rst
+++ b/AUTHORS.rst
@@ -382,6 +382,7 @@ Eric Lopez  elo...@nicira.com
 Frido Roose fr.ro...@gmail.com
 Gaetano Catalli gaetano.cata...@gmail.com
 Gavin Remaley   gavin_rema...@selinc.com
+Georg Schmuecking   georg.schmueck...@ericsson.com
 George Shuklin  ama...@desunote.ru
 Gerald Rogers   gerald.rog...@intel.com
 Ghanem Bahribahri.gha...@gmail.com
diff --git a/Documentation/howto/dpdk.rst b/Documentation/howto/dpdk.rst
index d1e6e89..f2e888b 100644
--- a/Documentation/howto/dpdk.rst
+++ b/Documentation/howto/dpdk.rst
@@ -354,6 +354,26 @@ the `DPDK documentation
 
 Note: Not all DPDK virtual PMD drivers have been tested and verified to work.
 
+EMC Insertion Probability
+-
+By default 1 in every 100 flows are inserted into the Exact Match Cache (EMC).
+It is possible to change this insertion probability by setting the
+``emc-insert-prob`` option::
+
+$ ovs-vsctl --no-wait set Open_vSwitch . other_config:emc-insert-prob=N
+
+where:
+
+``N``
+  is a positive integer between 0 and 4294967295 (maximum unsigned 32bit int).
+
+If ``N`` is set to 1, an insertion will be performed for every flow. The lower
+the value of ``emc-insert-prob`` the higher the probability of insertion,
+except for the value 0 which will result in no insertions being performed and
+thus essentially disabling the EMC.
+
+For more information on the EMC refer to :doc:`/intro/install/dpdk` .
+
 .. _dpdk-ovs-in-guest:
 
 OVS with DPDK Inside VMs
diff --git a/NEWS b/NEWS
index aebd99c..b353d21 100644
--- a/NEWS
+++ b/NEWS
@@ -70,6 +70,8 @@ v2.7.0 - xx xxx 
specified.
  * Virtual DPDK Poll Mode Driver (vdev PMD) support.
  * Removed experimental tag.
+ * EMC insertion probability is reduced to 1/100 and is configurable via
+   the new 'other_config:emc-insert-prob' option.
- Fedora packaging:
  * A package upgrade does not automatically restart OVS service.
- ovs-vswitchd/ovs-vsctl:
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 0be5db5..e99b466 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -144,6 +144,10 @@ struct netdev_flow_key {
 #define EM_FLOW_HASH_MASK (EM_FLOW_HASH_ENTRIES - 1)
 #define EM_FLOW_HASH_SEGS 2
 
+/* Default EMC insert probability is 1 / DEFAULT_EM_FLOW_INSERT_PROB */
+#define DEFAULT_EM_FLOW_INSERT_PROB 100
+#define DEFAULT_EM_FLOW_INSERT_MIN (UINT32_MAX / DEFAULT_EM_FLOW_INSERT_PROB)
+
 struct emc_entry {
 struct dp_netdev_flow *flow;
 struct netdev_flow_key key;   /* key.hash used for emc hash value. */
@@ -254,6 +258,9 @@ struct dp_netdev {
 uint64_t last_tnl_conf_seq;
 
 struct conntrack conntrack;
+
+/* Probability of EMC insertions is a factor of 'emc_insert_min'.*/
+OVS_ALIGNED_VAR(CACHE_LINE_SIZE)atomic_uint32_t emc_insert_min;
 };
 
 static struct dp_netdev_port *dp_netdev_lookup_port(const struct dp_netdev *dp,
@@ -1066,6 +1073,8 @@ create_dp_netdev(const char *name, const struct 
dpif_class *class,
 
 

Re: [ovs-dev] NEW ORDER

[sales]

Dear Sir,
Hello!

Can you please offer us the attached?

Pls send your quotation.

Thank you!
Best regards,



BENATIS KENOVA

Purchase Officer

Description: Description: Description: 
http://www.asqalan.ae/images/logo.png




Tel: + 971-2-6422994

Fax: + 971-2-6420109

Mob: 056 4067804

E-mail. i...@termalasya.com

PO box: 5827, Abu Dhabi, UAE

This email may contain confidential information and legally privileged. 
If you are not the intended recipient, you must not copy, distribute or 
take any action in reliance upon it and please notify the sender and 
delete the original mail and all copies thereof from your system 
immediately. This email has - been scanned for viruses and cleared by 
MailFirewall , however, internet communications can not be guaranteed to 
secure Timely, error , or virus free. The views are Expressed in esta 
mail Solely Those of the sender and do not Necessary That Reflect of 
Asqalan , UNLESS officially confirmed.Asqalan do not accept any 
consequential liability, damage or obligation for the sender of the 
emails.


P Save a tree ... please do not print this e-mail UNLESS you really need 
to
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 1/1] doc: Clarify how user space is experimental.

[Stokes, Ian]

> On 8 February 2017 at 02:08, Ian Stokes  wrote:
> > Clarify that the use of the user space datapath with non DPDK devices
> > is considered experimental.
> >
> > Fixes: 602e24ee189b (doc: Remove experimental warning for DPDK.)
> > Signed-off-by: Ian Stokes 
> > Co-authored-by: Joe Stringer 
> > ---
> 
> I suspect this got caught up in the ovs-dev filter, but it looks good to
> me so I applied this to master and branch-2.7.

Thanks Joe,

I can see it on the 2.7 branch but not master, did it fail to apply? I can 
re-submit if needs be.

Ian
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev