Re: [ovs-dev] [PATCH 2/2] dpif-netdev: Indicate support for various ct features.

[Justin Pettit]

> On Jul 19, 2017, at 3:18 PM, Darrell Ball  wrote:
> 
> I could not see any;  it is good the impact from this hybrid support thing 
> was limited
> to debug o/p then.
> I don't see any new issues from this patch addition, and it is the only 
> reasonable
> option for backporting.
> 
> In your original commit message, you said:
> 
> "The userspace datapath hardcodes support for the features it supports,
> but it was missing "ct_state_nat", "ct_orig_tuple", and "ct_orig_tuple6"."
> 
> Can you modify that so that it reflects that it is partially true and the 
> impact
> we now know/assume is limited to debug o/p per your confirmation..

Okay, I updated the patch as follows and pushed it to master:

-=-=-=-=-=-=-=-=-
The userspace datapath uses a structure to indicate supported features
that affects debug output.  This commit updates that structure to
indicate that "ct_state_nat", "ct_orig_tuple", and "ct_orig_tuple6" are
supported.
-=-=-=-=-=-=-=-=-

> Otherwise 
> Acked-by: Darrell Ball 

Thanks,

--Justin


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

[ovs-dev] [PATCH] vswitch.xml:Add detail variable for forward-bpdu reserved mac address in ovs-vswitchd.conf.db manpage

[闫峻函]

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

Re: [ovs-dev] [RFC PATCH v1] net-dpdk: Introducing TX tcp HW checksum offload support for DPDK pnic

[Gao Zhenyu]

Let me correct some words:
"The result of patch-SW-CKSUM means it skip netdev_prepare_tx_csum and
execute "ethto" "

The result of patch-SW-CKSUM means it skips netdev_prepare_tx_csum and
execute "ethtool -K eth0 tx off" in VM side.
So it consume VM's cksum function for tcp/udp packets.

2017-07-20 10:52 GMT+08:00 Gao Zhenyu :

> Hi Sugesh,
>
> the setup like:
>
>  qperf client
> +-+
> |   VM|
> +-+
>  |
>  |  qperf server
> +--+  ++
> | vswitch+dpdk |  | bare-metal |
> +--+  ++
>||
>||
>   pNic-PhysicalSwitch
>
>
> I am woking on a version patch, and the patch doesn't disable
> VIRTIO_NET_F_CSUM in netdev_dpdk_vhost_class_init.(So virtio-net can
> support NETIF_F_HW_CSUM | NETIF_F_SG) Besides of that, I implement UDP
> HW-cksum as well.
>
> Here is some performance testing result base on latest ovs. For udp jumbo
> packet,VM always comput it by itself because of mtu(1500) and IP fragment.
> So it doesn't show improvment on it.
> The result of patch-SW-CKSUM means it skip netdev_prepare_tx_csum and
> execute "ethto"
>
> qperf -t 60 -oo msg_size:1:64K:*2  10.100.85.247 tcp_bw tcp_lat udp_bw
> udp_lat
> without-patch(cksum in VM)  patch-SW-CKSUM(cksum in VM)
> patch-HW-CKSUM
> tcp_bw:
> bw  =  1.95 MB/sec 1.93 MB/sec  1.9 MB/sec
> tcp_bw:
> bw  =  3.93 MB/sec 3.83 MB/sec  3.83 MB/sec
> tcp_bw:
> bw  =  8.04 MB/sec 7.81 MB/sec  7.71 MB/sec
> tcp_bw:
> bw  =  15.3 MB/sec 14.7 MB/sec  14.5 MB/sec
> tcp_bw:
> bw  =  29.6 MB/sec 27.4 MB/sec  27 MB/sec
> tcp_bw:
>  bw  =  54.5 MB/sec50.7 MB/sec  50.5 MB/sec
> tcp_bw:
> bw  =  92.9 MB/sec 83.7 MB/sec  82.6 MB/sec
> tcp_bw:
> bw  =  147 MB/sec  144 MB/sec   146 MB/sec
> tcp_bw:
> bw  =  194 MB/sec  203 MB/sec   211 MB/sec
> tcp_bw:
> bw  =  255 MB/sec  253 MB/sec   257 MB/sec
> tcp_bw:
>  bw  =  303 MB/sec 294 MB/sec   301 MB/sec
> tcp_bw:
> bw  =  337 MB/sec  354 MB/sec   379 MB/sec
> tcp_bw:
> bw  =  402 MB/sec  506 MB/sec   556 MB/sec
> tcp_bw:
> bw  =  444 MB/sec  698 MB/sec   800 MB/sec
> tcp_bw:
> bw  =  468 MB/sec  866 MB/sec   1.03 GB/sec
> tcp_bw:
>  bw  =  477 MB/sec 985 MB/sec   1.11 GB/sec
> tcp_bw:
> bw  =  517 MB/sec  1.09 GB/sec  1.17 GB/sec
> tcp_lat:
> latency  =  28.8 us29.4 us  29.8 us
> tcp_lat:
> latency  =  28.5 us29.3 us  29.6 us
> tcp_lat:
> latency  =  28.7 us29.3 us  29.5 us
> tcp_lat:
>  latency  =  28.6 us   29.3 us  29.5 us
> tcp_lat:
> latency  =  28.6 us29.3 us  29.7 us
> tcp_lat:
> latency  =  28.6 us29.5 us  29.9 us
> tcp_lat:
> latency  =  29 us  29.8 us  30.4 us
> tcp_lat:
> latency  =  29.2 us30.3 us  30.2 us
> tcp_lat:
>  latency  =  30.4 us   30.9 us  31 us
> tcp_lat:
> latency  =  43.6 us32.2 us  32.3 us
> tcp_lat:
> latency  =  47.8 us34.3 us  34.7 us
> tcp_lat:
> latency  =  43.3 us44.2 us  44.1 us
> tcp_lat:
> latency  =  47.4 us48 us47.1 us
> tcp_lat:
>  latency  =  76.9 us   75.9 us  76.8 us
> tcp_lat:
> latency  =  83.5 us83.1 us  84.1 us
> tcp_lat:
> latency  =  134 us 94.6 us  96.1 us
> tcp_lat:
> latency  =  184 us 203 us   196 us
> udp_bw:
> send_bw  =  399 KB/sec send_bw  =  397 KB/sec   send_bw
> =  405 KB/sec
> recv_bw  =  392 KB/sec recv_bw  =  389 KB/sec   recv_bw
> =  398 KB/sec
> udp_bw:
>  send_bw  =  812 KB/secsend_bw  =  788 KB/sec   send_bw
> =  812 KB/sec
> recv_bw  =  800 KB/sec recv_bw  =  773 KB/sec   recv_bw
> =  800 KB/sec
> udp_bw:
> send_bw  =  1.64 MB/secsend_bw  =  1.59 MB/sec  send_bw
> =  1.61 MB/sec
> recv_bw  =  1.63 MB/secrecv_bw  =  1.53 MB/sec  recv_bw
> =  1.58 MB/sec
> udp_bw:
> send_bw  =  3.25 MB/sec   

Re: [ovs-dev] [RFC PATCH v1] net-dpdk: Introducing TX tcp HW checksum offload support for DPDK pnic

[Gao Zhenyu]

Hi Sugesh,

the setup like:

 qperf client
+-+
|   VM|
+-+
 |
 |  qperf server
+--+  ++
| vswitch+dpdk |  | bare-metal |
+--+  ++
   ||
   ||
  pNic-PhysicalSwitch


I am woking on a version patch, and the patch doesn't disable
VIRTIO_NET_F_CSUM in netdev_dpdk_vhost_class_init.(So virtio-net can
support NETIF_F_HW_CSUM | NETIF_F_SG) Besides of that, I implement UDP
HW-cksum as well.

Here is some performance testing result base on latest ovs. For udp jumbo
packet,VM always comput it by itself because of mtu(1500) and IP fragment.
So it doesn't show improvment on it.
The result of patch-SW-CKSUM means it skip netdev_prepare_tx_csum and
execute "ethto"

qperf -t 60 -oo msg_size:1:64K:*2  10.100.85.247 tcp_bw tcp_lat udp_bw
udp_lat
without-patch(cksum in VM)  patch-SW-CKSUM(cksum in VM)
patch-HW-CKSUM
tcp_bw:
bw  =  1.95 MB/sec 1.93 MB/sec  1.9 MB/sec
tcp_bw:
bw  =  3.93 MB/sec 3.83 MB/sec  3.83 MB/sec
tcp_bw:
bw  =  8.04 MB/sec 7.81 MB/sec  7.71 MB/sec
tcp_bw:
bw  =  15.3 MB/sec 14.7 MB/sec  14.5 MB/sec
tcp_bw:
bw  =  29.6 MB/sec 27.4 MB/sec  27 MB/sec
tcp_bw:
 bw  =  54.5 MB/sec50.7 MB/sec  50.5 MB/sec
tcp_bw:
bw  =  92.9 MB/sec 83.7 MB/sec  82.6 MB/sec
tcp_bw:
bw  =  147 MB/sec  144 MB/sec   146 MB/sec
tcp_bw:
bw  =  194 MB/sec  203 MB/sec   211 MB/sec
tcp_bw:
bw  =  255 MB/sec  253 MB/sec   257 MB/sec
tcp_bw:
 bw  =  303 MB/sec 294 MB/sec   301 MB/sec
tcp_bw:
bw  =  337 MB/sec  354 MB/sec   379 MB/sec
tcp_bw:
bw  =  402 MB/sec  506 MB/sec   556 MB/sec
tcp_bw:
bw  =  444 MB/sec  698 MB/sec   800 MB/sec
tcp_bw:
bw  =  468 MB/sec  866 MB/sec   1.03 GB/sec
tcp_bw:
 bw  =  477 MB/sec 985 MB/sec   1.11 GB/sec
tcp_bw:
bw  =  517 MB/sec  1.09 GB/sec  1.17 GB/sec
tcp_lat:
latency  =  28.8 us29.4 us  29.8 us
tcp_lat:
latency  =  28.5 us29.3 us  29.6 us
tcp_lat:
latency  =  28.7 us29.3 us  29.5 us
tcp_lat:
 latency  =  28.6 us   29.3 us  29.5 us
tcp_lat:
latency  =  28.6 us29.3 us  29.7 us
tcp_lat:
latency  =  28.6 us29.5 us  29.9 us
tcp_lat:
latency  =  29 us  29.8 us  30.4 us
tcp_lat:
latency  =  29.2 us30.3 us  30.2 us
tcp_lat:
 latency  =  30.4 us   30.9 us  31 us
tcp_lat:
latency  =  43.6 us32.2 us  32.3 us
tcp_lat:
latency  =  47.8 us34.3 us  34.7 us
tcp_lat:
latency  =  43.3 us44.2 us  44.1 us
tcp_lat:
latency  =  47.4 us48 us47.1 us
tcp_lat:
 latency  =  76.9 us   75.9 us  76.8 us
tcp_lat:
latency  =  83.5 us83.1 us  84.1 us
tcp_lat:
latency  =  134 us 94.6 us  96.1 us
tcp_lat:
latency  =  184 us 203 us   196 us
udp_bw:
send_bw  =  399 KB/sec send_bw  =  397 KB/sec   send_bw  =
405 KB/sec
recv_bw  =  392 KB/sec recv_bw  =  389 KB/sec   recv_bw  =
398 KB/sec
udp_bw:
 send_bw  =  812 KB/secsend_bw  =  788 KB/sec   send_bw  =
812 KB/sec
recv_bw  =  800 KB/sec recv_bw  =  773 KB/sec   recv_bw  =
800 KB/sec
udp_bw:
send_bw  =  1.64 MB/secsend_bw  =  1.59 MB/sec  send_bw  =
1.61 MB/sec
recv_bw  =  1.63 MB/secrecv_bw  =  1.53 MB/sec  recv_bw  =
1.58 MB/sec
udp_bw:
send_bw  =  3.25 MB/secsend_bw  =  3.16 MB/sec  send_bw  =
3.24 MB/sec
recv_bw  =  3.23 MB/secrecv_bw  =  3.05 MB/sec  recv_bw  =
3.13 MB/sec
udp_bw:
send_bw  =  6.59 MB/secsend_bw  =  6.35 MB/sec  send_bw  =
6.43 MB/sec
recv_bw  =   6.5 MB/secrecv_bw  =  6.22 MB/sec  recv_bw  =
6.22 MB/sec
udp_bw:
send_bw  =13 MB/secsend_bw  =  12.5 MB/sec  send_bw  =
12.8 MB/sec
recv_bw  =  12.9 MB/secrecv_bw  =  12.3 MB/sec  recv_bw  =
12.4 MB/sec
udp_bw:
 send_bw  =  26.1 MB/sec   send_bw  =  25.3 MB/sec  send_bw  

[ovs-dev] Add detail for ovs-vswitchd.conf.db manpage

[JunhanYan]

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

Re: [ovs-dev] [PATCH v2] odp-execute: Reuse rss hash in OVS_ACTION_ATTR_HASH.

[Darrell Ball]

-Original Message-
From: Darrell Ball 
Date: Tuesday, July 18, 2017 at 11:42 AM
To: Ilya Maximets , "ovs-dev@openvswitch.org" 
, Andy Zhou 
Cc: Heetae Ahn 
Subject: Re: [ovs-dev] [PATCH v2] odp-execute: Reuse rss hash in 
OVS_ACTION_ATTR_HASH.



On 7/17/17, 11:19 PM, "Ilya Maximets"  wrote:

On 18.07.2017 06:48, Darrell Ball wrote:
> 
> 
> On 7/13/17, 8:07 AM, "ovs-dev-boun...@openvswitch.org on behalf of 
Ilya Maximets"  wrote:
> 
> If RSS hash exists in a packet it can be reused instead of
> 5 tuple hash re-calculation in OVS_ACTION_ATTR_HASH. This
> leads to increasing the performance of sending packets to
> the OVS bonding in userspace datapath up to 10-15%.
> 
> Additionally fixed unit test 'select group with dp_hash
> selection method' to not depend on dp_hash value.
> 
> Signed-off-by: Ilya Maximets 
> ---
> 
> Version 2:
>   * Removed assumption on hash_basis value.
>   * hash_finish replaced with hash_int as more appropriate.
>   * Fixed 'select group with dp_hash selection method' UT.
> 
>  lib/odp-execute.c | 11 +--
>  tests/ofproto-dpif.at |  4 ++--
>  2 files changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/lib/odp-execute.c b/lib/odp-execute.c
> index d656334..03120bf 100644
> --- a/lib/odp-execute.c
> +++ b/lib/odp-execute.c
> @@ -646,8 +646,15 @@ odp_execute_actions(void *dp, struct 
dp_packet_batch *batch, bool steal,
>  uint32_t hash;
>  
>  DP_PACKET_BATCH_FOR_EACH (packet, batch) {
> -flow_extract(packet, );
> -hash = flow_hash_5tuple(, 
hash_act->hash_basis);
> +/* RSS hash can be used here instead of 
5tuple for
> + * performance reasons. */
> +if (dp_packet_rss_valid(packet)) {
> +hash = dp_packet_get_rss_hash(packet);
> +hash = hash_int(hash, 
hash_act->hash_basis);
> +} else {
> +flow_extract(packet, );
> +hash = flow_hash_5tuple(, 
hash_act->hash_basis);
> +}
> 
> Presently, OVS does not have configurable hashing fields for bonds, 
although this seems to be asked for.
> Also, OVS does not have symmetrical hashing for bonding, as exists 
for the multipath action.
> If/when these features are added, taking the RSS of various input 
interfaces to hash across the outgoing members of
> a given bond would not automatically work since a flexible hash 
algorithm would not be easily configured the same
> across different input devices and also enforcing symmetry would be 
similarly difficult.
> Potentially, we could also make these features mutually exclusive 
with using the RSS hash as is done here.
> 
> This patch does offer some performance gain, so we could revisit as 
needed in the above cases ?

For configurable hashing fields, I think, there should be different 
OVS_HASH_ALG type.

Right now the only algorithm is OVS_HASH_ALG_L4
So, if/when the hash algorithm becomes configurable, then others would come 
in or maybe field specifiers. 

Symmetric hashing is also not required for bonding to work correctly.

Symmetric hashing is a specific feature that requires the hash used to 
transmit the packet to be same on each end.
This would require matching configuration on each end. However, using the 
RSS hashes of the input 
interfaces going to the bond on each end is going to be hard to get to work 
since we don’t control them today in a
manner we would need to for this to work.
We could add code that tries to make them the same, but it will not work in 
some cases.

From the other side kernel datapath uses exactly same thing to execute 
OVS_ACTION_ATTR_HASH.
skb_get_hash() is used there which is equal to RSS hash if it available.
So, this patch just unifies kernel and userspace ways to execute hash 
actions.

We don’t control the associated kernel side configuration through OVS APIs 
today and it is not clear to me
that would happen any time soon, so kernel side may be a moot point 

Re: [ovs-dev] [PATCH 2/2] dpif-netdev: Indicate support for various ct features.

[Darrell Ball]

-Original Message-
From:  on behalf of Joe Stringer 
Date: Wednesday, July 19, 2017 at 2:54 PM
To: Darrell Ball 
Cc: "d...@openvswitch.org" 
Subject: Re: [ovs-dev] [PATCH 2/2] dpif-netdev: Indicate support for various ct 
features.

On 19 July 2017 at 14:11, Darrell Ball  wrote:
> On Wed, Jul 19, 2017 at 1:18 PM, Darrell Ball  wrote:
>> On Wed, Jul 19, 2017 at 12:17 PM, Justin Pettit  wrote:
>>> > On Jul 19, 2017, at 10:45 AM, Darrell Ball  wrote:
>>> > On 7/19/17, 8:01 AM, "Justin Pettit"  wrote:
>>> >> On Jul 19, 2017, at 2:45 AM, Darrell Ball  wrote:
>>> >> static struct odp_support dp_netdev_support = {
>>> >>   .max_vlan_headers = SIZE_MAX,
>>> >>   .max_mpls_depth = SIZE_MAX,
>>> >>   .recirc = false,
>>> >>   .ct_state = false,
>>> >>   .ct_zone = false,
>>> >>   .ct_mark = false,
>>> >>   .ct_label = false,
>>> >>   .ct_state_nat = false,
>>> >>   .ct_orig_tuple = false,
>>> >>   .ct_orig_tuple6 = false,
>>> >> };
>>> >>
>>> >> I think it may be better to clean this up. I can do this if you are 
ok
>>> with that; either way is fine with me.
>>> >
>>> >I agree that since the datapath features are probed, we should pass
>>> those parameters around instead of using these hardcoded values.  
However,
>>> it was a more invasive change than I wanted to make at the time, and I'd
>>> want to apply this fix regardless.  I was going to add using the probed
>>> values to my to-do list, but I'm happy if you want to take it.
>>> >
>>> > If there is a pressing reason to make a temporary fix, then that is
>>> fine.
>>>
>>> This seems like an obvious fix, and can be safely backported to earlier
>>> version.  I agree that feature-probing is a better long-term solution, 
but
>>> I'd prefer to backport this rather than a bigger change.  I would have
>>> proposed this patch anyway.
>>>
>>
>
> [Darrell] Backporting may not apply here as none of Jarno's original tuple
> code made it
>   to 2.7
> ///

I think that ct_state_nat was there though, so that bit should
probably be backported.
__

[Darrell] NAT is not applicable to 2.7 for Userspace.

_
dev mailing list
d...@openvswitch.org

https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=MH9-495CT68FfpGi4AKGJPvMdFdMFBWa8begcqVEjt8=TiEwlusIM4xqR6YeTyeLGZ1uF7m_4Va85Z3qZgfHDaE=
 


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

Re: [ovs-dev] [PATCH 2/2] dpif-netdev: Indicate support for various ct features.

[Joe Stringer]

On 19 July 2017 at 14:11, Darrell Ball  wrote:
> On Wed, Jul 19, 2017 at 1:18 PM, Darrell Ball  wrote:
>> On Wed, Jul 19, 2017 at 12:17 PM, Justin Pettit  wrote:
>>> > On Jul 19, 2017, at 10:45 AM, Darrell Ball  wrote:
>>> > On 7/19/17, 8:01 AM, "Justin Pettit"  wrote:
>>> >> On Jul 19, 2017, at 2:45 AM, Darrell Ball  wrote:
>>> >> static struct odp_support dp_netdev_support = {
>>> >>   .max_vlan_headers = SIZE_MAX,
>>> >>   .max_mpls_depth = SIZE_MAX,
>>> >>   .recirc = false,
>>> >>   .ct_state = false,
>>> >>   .ct_zone = false,
>>> >>   .ct_mark = false,
>>> >>   .ct_label = false,
>>> >>   .ct_state_nat = false,
>>> >>   .ct_orig_tuple = false,
>>> >>   .ct_orig_tuple6 = false,
>>> >> };
>>> >>
>>> >> I think it may be better to clean this up. I can do this if you are ok
>>> with that; either way is fine with me.
>>> >
>>> >I agree that since the datapath features are probed, we should pass
>>> those parameters around instead of using these hardcoded values.  However,
>>> it was a more invasive change than I wanted to make at the time, and I'd
>>> want to apply this fix regardless.  I was going to add using the probed
>>> values to my to-do list, but I'm happy if you want to take it.
>>> >
>>> > If there is a pressing reason to make a temporary fix, then that is
>>> fine.
>>>
>>> This seems like an obvious fix, and can be safely backported to earlier
>>> version.  I agree that feature-probing is a better long-term solution, but
>>> I'd prefer to backport this rather than a bigger change.  I would have
>>> proposed this patch anyway.
>>>
>>
>
> [Darrell] Backporting may not apply here as none of Jarno's original tuple
> code made it
>   to 2.7
> ///

I think that ct_state_nat was there though, so that bit should
probably be backported.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v4 0/3] tunneling : Improving tunneling performance by avoiding dp recirc.

[Joe Stringer]

On 19 July 2017 at 06:46, Sugesh Chandran  wrote:
> 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 also extended with 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.
>
> Signed-off-by: Sugesh Chandran 
> Signed-off-by: Zoltán Balogh 
> Co-authored-by: Zoltán Balogh 
>
> v4
>  - Rebased on latest master.
>  - Coding style fixes
>  - Provide comment for tunnel-push without post actions.
>  - Corrected new packet-aware test suites to pass userspace testsuites.
>  - Changes on cache_steal function to use memcpy and ofpbuf_put_uninit
>functions.
>
> v3
>  - Rebased on latest master
>  - Changed the xlate_cache copy function to avoid expensive ref update 
> operations.
>  - Updated the new packet-aware test cases to handle the non-recirc tunnel 
> case.
>  - Updated the commit message with performance results.
>
> v2
>  - Rebased on latest master.
>  - Updated newely added packet-aware test case to honor tunnel  combine 
> actions.
>  - Folded related patches into single patch based on Joe's comments.
>  - Do the translation only once for tunnel combine instead of two.
>
>
> Sugesh Chandran (3):
>   xlate: Clear tunnel mask along with other fields while combine
> actions.
>   tunneling: Calculate and update packet l4_offset in tunnel push.
>   tunneling: Avoid datapath-recirc by combining recirc actions at xlate.
>
>  lib/dpif-netdev.c   |  18 +--
>  lib/netdev-native-tnl.c |   2 +
>  ofproto/ofproto-dpif-xlate-cache.c  |  32 +++-
>  ofproto/ofproto-dpif-xlate-cache.h  |  13 +-
>  ofproto/ofproto-dpif-xlate.c| 238 
> +++-
>  ofproto/ofproto-dpif.c  |   3 +-
>  tests/packet-type-aware.at  |  27 ++--
>  tests/system-userspace-packet-type-aware.at |  24 +--
>  8 files changed, 296 insertions(+), 61 deletions(-)
>
> --
> 2.7.4
>

Thanks Sugesh and Zoltán, I applied this series to master with the
following minor style incremental to the last patch:

diff --git a/lib/netdev-native-tnl.c b/lib/netdev-native-tnl.c
index 5dbf5833dfb8..ef579409b0d0 100644
--- a/lib/netdev-native-tnl.c
+++ b/lib/netdev-native-tnl.c
@@ -139,7 +139,7 @@ netdev_tnl_ip_extract_tnl_md(struct dp_packet
*packet, struct flow_tnl *tnl,
 *
 * This function sets the IP header's ip_tot_len field (which should be zeroed
 * as part of 'header') and puts its value into '*ip_tot_size' as well.  Also
- * updates IP header checksum.
+ * updates IP header checksum, as well as the l3 and l4 offsets in 'packet'.
 *
 * Return pointer to the L4 header added to 'packet'. */
void *
diff --git a/ofproto/ofproto-dpif-xlate-cache.c
b/ofproto/ofproto-dpif-xlate-cache.c
index 6947f2fd318d..d319d287eadb 100644
--- a/ofproto/ofproto-dpif-xlate-cache.c
+++ b/ofproto/ofproto-dpif-xlate-cache.c
@@ -300,9 +300,10 @@ xlate_cache_steal_entries(struct xlate_cache
*dst, struct xlate_cache *src)
if (!dst || !src) {
return;
}
-void *p;
struct ofpbuf *src_entries = >entries;
struct ofpbuf *dst_entries = >entries;
+void *p;
+
p = ofpbuf_put_uninit(dst_entries, src_entries->size);
memcpy(p, src_entries->data, src_entries->size);
ofpbuf_clear(src_entries);
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 0177f5c15b71..7f7adb280eaf 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -3326,13 +3326,13 @@ validate_and_combine_post_tnl_actions(struct
xlate_ctx *ctx,
/* Update the CLONE action only when combined. */
nl_msg_end_nested(ctx->odp_actions, clone_ofs);
} else {
+nl_msg_cancel_nested(ctx->odp_actions, clone_ofs);
/* XXX : There is no real use-case for a tunnel push without
 * any post actions. However keeping it now
 * as is to make the 'make check' happy. Should remove when all the
 * make check tunnel test case does something meaningful on a
 * tunnel encap packets.
 */
-nl_msg_cancel_nested(ctx->odp_actions, clone_ofs);
odp_put_tnl_push_action(ctx->odp_actions, _push_data);
}
___
dev mailing list
d...@openvswitch.org

Re: [ovs-dev] [PATCH 2/2] dpif-netlink: For non-Ethernet, use Ethertype from packet_type.

[Joe Stringer]

On 19 July 2017 at 08:56, Eric Garver  wrote:
> On Tue, Jul 18, 2017 at 03:32:44PM -0700, Joe Stringer wrote:
>> For non-Ethernet flows, when fixing up the netlink message we need make
>> sure to pass down a valid Ethertype. The kernel does not understand
>> packet_type so it's implicitly encoded by the absence of _ETHERNET and
>> exact match of _ETHERTYPE. Without this change match_validate in the
>> kernel complains when trying to match packets from L3 tunnels.
>> e.g.
>>   openvswitch: netlink: Unexpected mask (mask=110088, allowed=3d9804c)
>>
>> The mask use to always be set in xlate_wc_init() and xlate_wc_finish(),
>> but that changed for non-Ethernet frames with the commit listed below.
>>
>> Fixes: 3d4b2e6eb74e ("userspace: Add OXM field MFF_PACKET_TYPE")
>> Signed-off-by: Joe Stringer 
>> Co-authored-by: Eric Garver 
>> ---
>>  lib/dpif-netlink.c | 19 +--
>>  1 file changed, 17 insertions(+), 2 deletions(-)
>>
>> diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
>> index 63ef3de5c7d1..55effd1f91a8 100644
>> --- a/lib/dpif-netlink.c
>> +++ b/lib/dpif-netlink.c
>> @@ -3434,8 +3434,9 @@ dpif_netlink_flow_from_ofpbuf(struct dpif_netlink_flow 
>> *flow,
>>
>>
>>  /*
>> - * If PACKET_TYPE attribute is present in 'data', it filters PACKET_TYPE 
>> out,
>> - * then puts 'data' to 'buf'.
>> + * If PACKET_TYPE attribute is present in 'data', it filters PACKET_TYPE 
>> out.
>> + * If the flow is not Ethernet, the OVS_KEY_ATTR_PACKET_TYPE is converted to
>> + * OVS_KEY_ATTR_ETHERTYPE. Puts 'data' to 'buf'.
>>   */
>>  static void
>>  put_exclude_packet_type(struct ofpbuf *buf, uint16_t type,
>> @@ -3458,6 +3459,20 @@ put_exclude_packet_type(struct ofpbuf *buf, uint16_t 
>> type,
>>  ofs = nl_msg_start_nested(buf, type);
>>  nl_msg_put(buf, data, first_chunk_size);
>>  nl_msg_put(buf, next_attr, second_chunk_size);
>> +if (!nl_attr_find__(data, data_len, OVS_KEY_ATTR_ETHERNET)) {
>> +ovs_be16 pt = pt_ns_type_be(nl_attr_get_be32(packet_type));
>> +const struct nlattr *nla;
>> +
>> +nla = nl_attr_find(buf, NLA_HDRLEN, OVS_KEY_ATTR_ETHERTYPE);
>> +if (nla) {
>> +ovs_be16 *ethertype;
>> +
>> +ethertype = CONST_CAST(ovs_be16 *, nl_attr_get(nla));
>> +*ethertype = pt;
>> +} else {
>> +nl_msg_put_be16(buf, OVS_KEY_ATTR_ETHERTYPE, pt);
>> +}
>> +}
>>  nl_msg_end_nested(buf, ofs);
>>  } else {
>>  nl_msg_put_unspec(buf, type, data, data_len);
>> --
>> 2.11.1
>>
>
> Thanks Joe! This is definitely more concise than my version.
>
> Acked-by: Eric Garver 

Thanks for the review, applied to master.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 00/10] Support layer3 VXLAN-GPE and GRE in kernel datapath

[Joe Stringer]

On 18 July 2017 at 15:53, Joe Stringer  wrote:
> On 10 July 2017 at 12:39, Eric Garver  wrote:
>> This series enables support for layer3 tunnels VXLAN-GPE and GRE in the 
>> kernel
>> datapath. It includes new system-traffic test cases. The first two patches 
>> fix
>> an issue translating packet_type from flows for the kernel.
>>
>> Note: VXLAN-GPE depends on a fix recently posted to the list.
>> https://mail.openvswitch.org/pipermail/ovs-dev/2017-June/334788.html
>
> Thanks a lot for this work, Eric! It's nice to get some more coverage
> on this packet_type handling code.
>
> I've reviewed patches 1-2 and suggested another approach, once we
> figure that part out I'd be happy to apply the rest of the series.

I applied that series, then patches 3-10 of this series to master. Thanks Eric!
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH 1/8] acinclude.m4: Support Linux kernel 4.12

[Greg Rose]

Allow datapath kernel modules to be configured and built for kernels up
to 4.12.

Adds a new define for the kernel compatibility layer to indicate whether
upstream commit cf124db566e6 ("net: Fix inconsistent teardown and release
of private netdev state.") is present.

Adds a new define for the kernel compatibility layer to indicate whether
upstream commit dc5321d79697 ("vxlan: get rid of redundant vxlan_dev.flags")
is present.

Adds a new define for the kernel compatibility layer to indicate whether
upstream commit d91fc59cd77c ("netfilter: introduce nf_conntrack_helper_put
helper function") is present.

Signed-off-by: Greg Rose 
---
 acinclude.m4 | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/acinclude.m4 b/acinclude.m4
index e7affc5..0be7a63 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -143,7 +143,7 @@ AC_DEFUN([OVS_CHECK_LINUX], [
 AC_MSG_RESULT([$kversion])
 
 if test "$version" -ge 4; then
-   if test "$version" = 4 && test "$patchlevel" -le 11; then
+   if test "$version" = 4 && test "$patchlevel" -le 12; then
   : # Linux 4.x
else
   AC_ERROR([Linux kernel in $KBUILD is version $kversion, but version 
newer than 4.11.x is not supported (please refer to the FAQ for advice)])
@@ -748,6 +748,15 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
 [OVS_DEFINE([HAVE_DEFRAG_ENABLE_TAKES_NET])])
   OVS_GREP_IFELSE([$KSRC/include/net/genetlink.h], [family_list],
 [OVS_DEFINE([HAVE_GENL_FAMILY_LIST])])
+  OVS_FIND_FIELD_IFELSE([$KSRC/include/linux/netdevice.h], [net_device],
+[needs_free_netdev],
+[OVS_DEFINE([HAVE_NEEDS_FREE_NETDEV])])
+  OVS_FIND_FIELD_IFELSE([$KSRC/include/net/vxlan.h], [vxlan_dev],
+[cfg],
+[OVS_DEFINE([HAVE_VXLAN_DEV_CFG])])
+  OVS_GREP_IFELSE([$KSRC/include/net/netfilter/nf_conntrack_helper.h],
+  [nf_conntrack_helper_put],
+  [OVS_DEFINE([HAVE_NF_CONNTRACK_HELPER_PUT])])
 
   if cmp -s datapath/linux/kcompat.h.new \
 datapath/linux/kcompat.h >/dev/null 2>&1; then
-- 
1.8.3.1

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

Re: [ovs-dev] [PATCH v2 2/2] openvswitch: Optimize operations for OvS flow_stats.

[David Miller]

From: Tonghao Zhang 
Date: Mon, 17 Jul 2017 23:28:06 -0700

> When calling the flow_free() to free the flow, we call many times
> (cpu_possible_mask, eg. 128 as default) cpumask_next(). That will
> take up our CPU usage if we call the flow_free() frequently.
> When we put all packets to userspace via upcall, and OvS will send
> them back via netlink to ovs_packet_cmd_execute(will call flow_free).
> 
> The test topo is shown as below. VM01 sends TCP packets to VM02,
> and OvS forward packtets. When testing, we use perf to report the
> system performance.
> 
> VM01 --- OvS-VM --- VM02
> 
> Without this patch, perf-top show as below: The flow_free() is
> 3.02% CPU usage.
> 
>   4.23%  [kernel][k] _raw_spin_unlock_irqrestore
>   3.62%  [kernel][k] __do_softirq
>   3.16%  [kernel][k] __memcpy
>   3.02%  [kernel][k] flow_free
>   2.42%  libc-2.17.so[.] __memcpy_ssse3_back
>   2.18%  [kernel][k] copy_user_generic_unrolled
>   2.17%  [kernel][k] find_next_bit
> 
> When applied this patch, perf-top show as below: Not shown on
> the list anymore.
> 
>   4.11%  [kernel][k] _raw_spin_unlock_irqrestore
>   3.79%  [kernel][k] __do_softirq
>   3.46%  [kernel][k] __memcpy
>   2.73%  libc-2.17.so[.] __memcpy_ssse3_back
>   2.25%  [kernel][k] copy_user_generic_unrolled
>   1.89%  libc-2.17.so[.] _int_malloc
>   1.53%  ovs-vswitchd[.] xlate_actions
> 
> With this patch, the TCP throughput(we dont use Megaflow Cache
> + Microflow Cache) between VMs is 1.18Gbs/sec up to 1.30Gbs/sec
> (maybe ~10% performance imporve).
> 
> This patch adds cpumask struct, the cpu_used_mask stores the cpu_id
> that the flow used. And we only check the flow_stats on the cpu we
> used, and it is unncessary to check all possible cpu when getting,
> cleaning, and updating the flow_stats. Adding the cpu_used_mask to
> sw_flow struct does’t increase the cacheline number.
> 
> Signed-off-by: Tonghao Zhang 
> Acked-by: Pravin B Shelar 

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

Re: [ovs-dev] [PATCH v2 1/2] openvswitch: Optimize updating for OvS flow_stats.

[David Miller]

From: Tonghao Zhang 
Date: Mon, 17 Jul 2017 23:28:05 -0700

> In the ovs_flow_stats_update(), we only use the node
> var to alloc flow_stats struct. But this is not a
> common case, it is unnecessary to call the numa_node_id()
> everytime. This patch is not a bugfix, but there maybe
> a small increase.
> 
> Signed-off-by: Tonghao Zhang 

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

Re: [ovs-dev] [PATCH 2/2] dpif-netdev: Indicate support for various ct features.

[Darrell Ball]

On Wed, Jul 19, 2017 at 12:17 PM, Justin Pettit  wrote:

>
> > On Jul 19, 2017, at 10:45 AM, Darrell Ball  wrote:
> >
> >
> >
> > On 7/19/17, 8:01 AM, "Justin Pettit"  wrote:
> >
> >
> >> On Jul 19, 2017, at 2:45 AM, Darrell Ball  wrote:
> >>
> >> This change does not seem to be all that useful.
> >>
> >> When rules are constructed, mask and action support do check previously
> probed support
> >> which will be ‘TRUE’.
> >>
> >> Another way to see that the below settings are not useful is to set
> everything to ‘false’ (see below) and run all
> >> the system tests in userspace, which will all pass.
> >
> >This change does affect behavior.  For example, upcall debug log
> messages will now show ct_orig_tuple members.  The reason
> >is that dp_netdev_upcall() passes those support parameters to
> odp_flow_key_from_flow(), which thinks that the datapath
> >doesn't support those features, so it doesn't print the values.
> >
> > I see, so you noticed it affected debug output.
> > I see the hardcoded values passed in 3 functions.
> > Was there any other impact you can foresee ?
>
> I don't.  Do you?
>

[Darrell]
I could not see any;  it is good the impact from this hybrid support thing
was limited
to debug o/p then.
I don't see any new issues from this patch addition, and it is the only
reasonable
option for backporting.

In your original commit message, you said:

"The userspace datapath hardcodes support for the features it supports,
but it was missing "ct_state_nat", "ct_orig_tuple", and "ct_orig_tuple6"."

Can you modify that so that it reflects that it is partially true and the
impact
we now know/assume is limited to debug o/p per your confirmation..

Otherwise
Acked-by: Darrell Ball 






> > Any additional test coverage you can recommend ?
>
> I don't think so, since likely future issues will come from adding new
> support features and not populating this structure--not from this reverting
> somehow.
>

[Darrell]
JTBC, I don't think populating this structure per this patch will cause any
additional issues.

I was more concerned that if there was any existing issues besides debug
o/p,
that we might not have full test coverage. But since we don't think that is
the case, the
additional testing is not needed.





>
> >> By the way, the .max_vlan_headers and .max_mpls_headers fields, which I
> did not change are pretty big
> >> numbers and I am fairly sure OVS does not really support that many
> vlans and labels.
> >>
> >> static struct odp_support dp_netdev_support = {
> >>   .max_vlan_headers = SIZE_MAX,
> >>   .max_mpls_depth = SIZE_MAX,
> >>   .recirc = false,
> >>   .ct_state = false,
> >>   .ct_zone = false,
> >>   .ct_mark = false,
> >>   .ct_label = false,
> >>   .ct_state_nat = false,
> >>   .ct_orig_tuple = false,
> >>   .ct_orig_tuple6 = false,
> >> };
> >>
> >> I think it may be better to clean this up. I can do this if you are ok
> with that; either way is fine with me.
> >
> >I agree that since the datapath features are probed, we should pass
> those parameters around instead of using these hardcoded values.  However,
> it was a more invasive change than I wanted to make at the time, and I'd
> want to apply this fix regardless.  I was going to add using the probed
> values to my to-do list, but I'm happy if you want to take it.
> >
> > If there is a pressing reason to make a temporary fix, then that is fine.
>
> This seems like an obvious fix, and can be safely backported to earlier
> version.  I agree that feature-probing is a better long-term solution, but
> I'd prefer to backport this rather than a bigger change.  I would have
> proposed this patch anyway.
>
> By the way, can you look at adjusting your email client to quote replies
> instead of merely indenting them?  It makes it hard to see what the other
> person was saying when you reply.


> --Justin
>
>
> ___
> 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 1/2] odp-util: Document size of OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV4.

[Justin Pettit]

> On Jul 19, 2017, at 10:58 AM, Joe Stringer  wrote:
> 
> On 18 July 2017 at 23:18, Justin Pettit  wrote:
>> This attribute shares space with OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV6, but
>> it's still worth documenting.
>> 
>> Signed-off-by: Justin Pettit 
> 
> Strictly speaking I guess that in the nlattr-formatted flow_key it is
> "mutually exclusive with _CT_ORIG_TUPLE_IPV6", which is bigger and
> therefore it's not worth counting against the total.

That's true.  I was trying to keep it consistent with the Geneve/VxLAN option. 
but it probably just made it confusing.  I changed the comments to indicate 
that it's "exclusive of". 

> Acked-by: Joe Stringer 

Thanks!

--Justin


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

[ovs-dev] Fwd: Tr : FW:RE: BønSoir!

[AB PROPO]

 

_> - Original Message -> - Original Message -> -
Original Message -_ 

_Je me présente M. Pietri Landry , c'est avec beaucoup_
_d'hésitation que je vous fais part de ce message. En effet je suis le_
_le responsable d'une banque détentrice d'une grosse somme. je
souhaiterai vous faire une offre qui pourrai vous intéressé. Pour vous
avoir plus d'infos, veuillez prendre consulter mon avis en PJ._
_C'est dans cette urgence que je vous demande de me ré-contacter;
landry.pie...@yahoo.com le plus vite possible_
_dès réception de ce courrier pour ample information._ 

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

Re: [ovs-dev] [PATCH 2/2] dpif-netdev: Indicate support for various ct features.

[Justin Pettit]

> On Jul 19, 2017, at 10:45 AM, Darrell Ball  wrote:
> 
> 
> 
> On 7/19/17, 8:01 AM, "Justin Pettit"  wrote:
> 
> 
>> On Jul 19, 2017, at 2:45 AM, Darrell Ball  wrote:
>> 
>> This change does not seem to be all that useful.
>> 
>> When rules are constructed, mask and action support do check previously 
>> probed support
>> which will be ‘TRUE’.
>> 
>> Another way to see that the below settings are not useful is to set 
>> everything to ‘false’ (see below) and run all
>> the system tests in userspace, which will all pass.
> 
>This change does affect behavior.  For example, upcall debug log messages 
> will now show ct_orig_tuple members.  The reason
>is that dp_netdev_upcall() passes those support parameters to 
> odp_flow_key_from_flow(), which thinks that the datapath
>doesn't support those features, so it doesn't print the values.
> 
> I see, so you noticed it affected debug output.
> I see the hardcoded values passed in 3 functions.
> Was there any other impact you can foresee ?

I don't.  Do you?

> Any additional test coverage you can recommend ?

I don't think so, since likely future issues will come from adding new support 
features and not populating this structure--not from this reverting somehow.

>> By the way, the .max_vlan_headers and .max_mpls_headers fields, which I did 
>> not change are pretty big
>> numbers and I am fairly sure OVS does not really support that many vlans and 
>> labels.
>> 
>> static struct odp_support dp_netdev_support = {
>>   .max_vlan_headers = SIZE_MAX,
>>   .max_mpls_depth = SIZE_MAX,
>>   .recirc = false,
>>   .ct_state = false,
>>   .ct_zone = false,
>>   .ct_mark = false,
>>   .ct_label = false,
>>   .ct_state_nat = false,
>>   .ct_orig_tuple = false,
>>   .ct_orig_tuple6 = false,
>> };
>> 
>> I think it may be better to clean this up. I can do this if you are ok with 
>> that; either way is fine with me.
> 
>I agree that since the datapath features are probed, we should pass those 
> parameters around instead of using these hardcoded values.  However, it was a 
> more invasive change than I wanted to make at the time, and I'd want to apply 
> this fix regardless.  I was going to add using the probed values to my to-do 
> list, but I'm happy if you want to take it.
> 
> If there is a pressing reason to make a temporary fix, then that is fine.

This seems like an obvious fix, and can be safely backported to earlier 
version.  I agree that feature-probing is a better long-term solution, but I'd 
prefer to backport this rather than a bigger change.  I would have proposed 
this patch anyway.

By the way, can you look at adjusting your email client to quote replies 
instead of merely indenting them?  It makes it hard to see what the other 
person was saying when you reply.

--Justin


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

Re: [ovs-dev] [PATCH v3] Update relevant artifacts to add support for DPDK 17.05.1.

[Darrell Ball]

On 7/19/17, 9:40 AM, "ovs-dev-boun...@openvswitch.org on behalf of Kevin 
Traynor"  
wrote:

On 07/19/2017 10:30 AM, Michal Weglicki wrote:
> Upgrading to DPDK 17.05.1 stable release adds new
> significant features relevant to OVS, including,
> but not limited to:
> - tun/tap PMD,
> - VFIO hotplug support,
> - Generic flow API.
> 
> Following changes are applied:
> - netdev-dpdk: Changes required by DPDK API modifications.
> - doc: Because of DPDK API changes, backward compatibility
>   with previous DPDK releases will be broken, thus all
>   relevant documentation entries are updated.
> - .travis: DPDK version change from 16.11.1 to 17.05.1.
> - rhel/openvswitch-fedora.spec.in: DPDK version change
>   from 16.11 to 17.05.1
> 

Hi Michal, were you able to check vhost features like multi-queue and
vhostclient reconnect are still working ok with this patch?

Few comments on the docs below.

> v1->v2: Patch rebase.
> v2->v3: Fixed wrong formating after v2 patch rebase.
> 
> Signed-off-by: Michal Weglicki 
> Reviewed-by: Aaron Conole 
> ---
>  .travis/linux-build.sh   |   2 +-
>  Documentation/intro/install/dpdk.rst |   8 +-
>  Documentation/topics/dpdk/vhost-user.rst |   8 +-
>  NEWS |   1 +
>  lib/netdev-dpdk.c| 144 
+++
>  rhel/openvswitch-fedora.spec.in  |   2 +-
>  tests/dpdk/ring_client.c |   6 +-
>  7 files changed, 105 insertions(+), 66 deletions(-)
> 
> diff --git a/.travis/linux-build.sh b/.travis/linux-build.sh
> index f66b534..efccdf1 100755
> --- a/.travis/linux-build.sh
> +++ b/.travis/linux-build.sh
> @@ -80,7 +80,7 @@ fi
>  
>  if [ "$DPDK" ]; then
>  if [ -z "$DPDK_VER" ]; then
> -DPDK_VER="16.11.2"
> +DPDK_VER="17.05.1"
>  fi
>  install_dpdk $DPDK_VER
>  if [ "$CC" = "clang" ]; then
> diff --git a/Documentation/intro/install/dpdk.rst 
b/Documentation/intro/install/dpdk.rst
> index a05aa1a..4a178f3 100644
> --- a/Documentation/intro/install/dpdk.rst
> +++ b/Documentation/intro/install/dpdk.rst
> @@ -40,7 +40,7 @@ Build requirements
>  In addition to the requirements described in :doc:`general`, building 
Open
>  vSwitch with DPDK will require the following:
>  
> -- DPDK 16.11
> +- DPDK 17.05.1
>  
>  - A `DPDK supported NIC`_
>  
> @@ -69,9 +69,9 @@ Install DPDK
>  #. Download the `DPDK sources`_, extract the file and set ``DPDK_DIR``::
>  
> $ cd /usr/src/
> -   $ wget 
https://urldefense.proofpoint.com/v2/url?u=http-3A__fast.dpdk.org_rel_dpdk-2D16.11.2.tar.xz=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=k97jBbskm5qtu47B5YEDKLa6LCgJq7IpV9fRXIASszk=VXewRbmVuHTeOAdaJZA9ivHiJCZFh617b1ay74Fjhqs=
 
> -   $ tar xf dpdk-16.11.2.tar.xz
> -   $ export DPDK_DIR=/usr/src/dpdk-stable-16.11.2
> +   $ wget 
https://urldefense.proofpoint.com/v2/url?u=http-3A__fast.dpdk.org_rel_dpdk-2D17.05.1.tar.xz=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=k97jBbskm5qtu47B5YEDKLa6LCgJq7IpV9fRXIASszk=2ExT20R-aUXe1Fm7vJWI1NTBBseyM6Tyz3youB2btL8=
 
> +   $ tar xf dpdk-17.05.1.tar.xz
> +   $ export DPDK_DIR=/usr/src/dpdk-stable-17.05.1
> $ cd $DPDK_DIR
>  
>  #. (Optional) Configure DPDK as a shared library

There is a reference to DPDK16.11 release notes at the end of this file

> diff --git a/Documentation/topics/dpdk/vhost-user.rst 
b/Documentation/topics/dpdk/vhost-user.rst
> index e76da5f..9f11ea1 100644
> --- a/Documentation/topics/dpdk/vhost-user.rst
> +++ b/Documentation/topics/dpdk/vhost-user.rst
> @@ -292,9 +292,9 @@ To begin, instantiate a guest as described in 
:ref:`dpdk-vhost-user` or
>  DPDK sources to VM and build DPDK::
>  
>  $ cd /root/dpdk/
> -$ wget 
https://urldefense.proofpoint.com/v2/url?u=http-3A__fast.dpdk.org_rel_dpdk-2D16.11.2.tar.xz=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=k97jBbskm5qtu47B5YEDKLa6LCgJq7IpV9fRXIASszk=VXewRbmVuHTeOAdaJZA9ivHiJCZFh617b1ay74Fjhqs=
 
> -$ tar xf dpdk-16.11.2.tar.xz
> -$ export DPDK_DIR=/root/dpdk/dpdk-stable-16.11.2
> +$ wget 
https://urldefense.proofpoint.com/v2/url?u=http-3A__fast.dpdk.org_rel_dpdk-2D17.05.1.tar.xz=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=k97jBbskm5qtu47B5YEDKLa6LCgJq7IpV9fRXIASszk=2ExT20R-aUXe1Fm7vJWI1NTBBseyM6Tyz3youB2btL8=
 
> +$ tar xf dpdk-17.05.1.tar.xz
> +$ export DPDK_DIR=/root/dpdk/dpdk-stable-17.05.1
>  $ export DPDK_TARGET=x86_64-native-linuxapp-gcc
>  $ export 

[ovs-dev] Debugging on openvswitch source code

[NOUGNANKE KOKOUVI BENOIT]

Hello,

I am trying to understand the openvswitch source code, in order to
customize some treatments.

For example, I would like, when a packet is received on the OVS bridge, to
know all the functions that are called and the processing that the packet
undergoes.
So I added VLOG_DBG ("") in some functions. After configuring the Vlog
with (ovs-appctl vlog / set ..) and checking the log files I do not see any
of my VLOG_DBG messages.

So I would like to know if someone could help me on this subject or propose
me methods that are used for debugging when modifying the source code of
OVS, like doing debugging with "printf" in a  source code.

Thank you

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

[ovs-dev] YOUR CONTRACT CONSIGMENT IN ATLANTA GEORGIA .

[marcel helmont]

Central Bank of Nigeria (C.B.N),
CBN CORPORATE HEADQUARTER, NNPC Towers, Central Business District,
P.M.B. 190, Garki, Abuja-Nigeria.

Compliment of the day!

Attn: Sir,

After our meetings few days ago,your contract funds consignment will
be paid in our security firm united states of American in your country
since you are there in USA you have to arrange your self proceed to
Atlanta Georgia and meet with the diplomat who come with your
consignment that is in charge of your funds payment in USA as soon as
i hear from you i will now send you his contact to arrange with him to
me face to face to receive your consignment in Atlanta Georgia by
diplomatic means.

You have to send your id card,international passport with your cell
phone number where the diplomat will reach you now.

Waiting to hear from you to enable you proceed and get paid.

Your urgent response is highly expected.

Yours faithfully,


Waiting for your urgent mail.

Mr. Marcel Helmont
Head of Banking Operations(Diplomatic Immunity)
The Central Bank of Nigeria.Central Bank of Nigeria (C.B.N)
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 1/2] odp-util: Document size of OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV4.

[Joe Stringer]

On 18 July 2017 at 23:18, Justin Pettit  wrote:
> This attribute shares space with OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV6, but
> it's still worth documenting.
>
> Signed-off-by: Justin Pettit 

Strictly speaking I guess that in the nlattr-formatted flow_key it is
"mutually exclusive with _CT_ORIG_TUPLE_IPV6", which is bigger and
therefore it's not worth counting against the total.

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

Re: [ovs-dev] [RFC PATCH v1] net-dpdk: Introducing TX tcp HW checksum offload support for DPDK pnic

[Chandran, Sugesh]

Hi Gao,
Thank you for working on this.
Great to see it gives some performance improvement.
Some comments/questions below.

Regards
_Sugesh

From: Gao Zhenyu [mailto:sysugaozhe...@gmail.com]
Sent: Monday, July 17, 2017 12:55 PM
To: Chandran, Sugesh 
Cc: b...@ovn.org; u9012...@gmail.com; d...@openvswitch.org
Subject: Re: [ovs-dev] [RFC PATCH v1] net-dpdk: Introducing TX tcp HW checksum 
offload support for DPDK pnic

Hi Sugesh,

   I did more performance testings on it.
   In ovs-dpdk + VM environment, I consumed qperf on VM side and has there 
performace number (left colunm is consuming Hardware CKSUM,  right colunm is 
consuming Software CKSUM).
[Sugesh] May I know what is the test setup is looks like?
Is it
PHY --> VM --> PHY
?
   we can see in tcp throughput part, it has big improvment. I would like to 
make HW-TCP-CKSUM enabled in default in next patch.
[Sugesh] Ok. Looks like the performance improvement is really visible if msg 
size is getting bigger.
Wondering what is the impact of this on other type of traffic (due to turning 
off vectorization)



[root@localhost ~]# qperf -t 60 -oo msg_size:1:64K:*2  10.100.85.247 tcp_bw 
tcp_lat
tcp_bw:   HW-CKSUM   SW-CKSUM(in VM)
bw  =  1.91 MB/sec  1.93 MB/sec
tcp_bw:
bw  =  4 MB/sec  3.97 MB/sec
tcp_bw:
bw  =  7.74 MB/sec  7.76 MB/sec
tcp_bw:
bw  =  14.7 MB/sec  14.7 MB/sec
tcp_bw:
bw  =  27.8 MB/sec  27.4 MB/sec
tcp_bw:
 bw  =  51.3 MB/sec  49.1 MB/sec
tcp_bw:
bw  =  87.5 MB/sec  83.1 MB/sec
tcp_bw:
bw  =  144 MB/sec  129 MB/sec
tcp_bw:
bw  =  203 MB/sec  189 MB/sec
tcp_bw:
bw  =  261 MB/sec  252 MB/sec
tcp_bw:
 bw  =  317 MB/sec  253 MB/sec
tcp_bw:
bw  =  400 MB/sec  307 MB/sec
tcp_bw:
bw  =  611 MB/sec  491 MB/sec
tcp_bw:
bw  =  912 MB/sec  662 MB/sec
tcp_bw:
bw  =  1.11 GB/sec  729 MB/sec
tcp_bw:
 bw  =  1.17 GB/sec  861 MB/sec
tcp_bw:
bw  =  1.17 GB/sec  1.08 GB/sec
tcp_lat:
latency  =  29.1 us  29.4 us
tcp_lat:
latency  =  28.8 us  29.1 us
tcp_lat:
latency  =  29 us  28.9 us
tcp_lat:
 latency  =  28.7 us  29.2 us
tcp_lat:
latency  =  29.2 us  28.9 us
tcp_lat:
latency  =  28.9 us  29.1 us
tcp_lat:
latency  =  29.4 us  29.4 us
tcp_lat:
latency  =  29.6 us  29.9 us
tcp_lat:
 latency  =  30.5 us  30.4 us
tcp_lat:
latency  =  47.1 us  39.8 us
tcp_lat:
latency  =  53.6 us  45.2 us
tcp_lat:
latency  =  43.5 us  44.4 us
tcp_lat:
latency  =  53.8 us  49.1 us
tcp_lat:
 latency  =  81.8 us  78.5 us
tcp_lat:
latency  =  82.3 us  83.3 us
tcp_lat:
latency  =  93.1 us  97.2 us
tcp_lat:
latency  =  237 us  211 us

2017-06-23 15:58 GMT+08:00 Chandran, Sugesh 
>:


Regards
_Sugesh

From: Gao Zhenyu 
[mailto:sysugaozhe...@gmail.com]
Sent: Wednesday, June 21, 2017 9:32 AM
To: Chandran, Sugesh 
>
Cc: b...@ovn.org; 
u9012...@gmail.com; 
ktray...@redhat.com; Kavanagh, Mark B 
>; 
d...@openvswitch.org
Subject: Re: [ovs-dev] [RFC PATCH v1] net-dpdk: Introducing TX tcp HW checksum 
offload support for DPDK pnic

I get it.  Maybe caculating it in OVS part is doable as well.
So, how about adding more options to let people choose HW-tcp-cksum(reduce cpu 
cycles) or SW-tcp-cksum(may be better performance)?
Then we have NO-TCP-CKSUM, SW-TCP-CKSUM, HW-TCP-CKSUM.
[Sugesh] In OVS-DPDK, I am not sure about the advantage of having HW checksum. 
Because even if you save CPU cycles, that will get used for non vector tx.
So I would prefer to keep these options only if there are really a need for 
that.
BTW, when will DPDK support tx checksum offload with vectorization?
[Sugesh] I don’t see any plan to do that in near future. Could be worth to ask 
in DPDK mailing list as well.

Thanks
Zhenyu Gao


2017-06-21 16:03 GMT+08:00 Chandran, Sugesh 
>:


Regards
_Sugesh

From: Gao Zhenyu 
[mailto:sysugaozhe...@gmail.com]
Sent: Monday, June 19, 2017 1:23 PM
To: Chandran, Sugesh 
>
Cc: b...@ovn.org; 
u9012...@gmail.com; 
ktray...@redhat.com; Kavanagh, Mark B 
>; 
d...@openvswitch.org
Subject: Re: [ovs-dev] [RFC PATCH v1] net-dpdk: Introducing TX tcp HW checksum 
offload support for DPDK pnic

Thanks for that comments.

[Sugesh] Any reason, why this patch does only the TCP checksum offload?? The 
command line option says tx_checksum offload (it could be mistakenly considered 
for full checksum offload).
[Zhenyu Gao] 

Re: [ovs-dev] [PATCH v3] Update relevant artifacts to add support for DPDK 17.05.1.

[Kevin Traynor]

On 07/19/2017 10:30 AM, Michal Weglicki wrote:
> Upgrading to DPDK 17.05.1 stable release adds new
> significant features relevant to OVS, including,
> but not limited to:
> - tun/tap PMD,
> - VFIO hotplug support,
> - Generic flow API.
> 
> Following changes are applied:
> - netdev-dpdk: Changes required by DPDK API modifications.
> - doc: Because of DPDK API changes, backward compatibility
>   with previous DPDK releases will be broken, thus all
>   relevant documentation entries are updated.
> - .travis: DPDK version change from 16.11.1 to 17.05.1.
> - rhel/openvswitch-fedora.spec.in: DPDK version change
>   from 16.11 to 17.05.1
> 

Hi Michal, were you able to check vhost features like multi-queue and
vhostclient reconnect are still working ok with this patch?

Few comments on the docs below.

> v1->v2: Patch rebase.
> v2->v3: Fixed wrong formating after v2 patch rebase.
> 
> Signed-off-by: Michal Weglicki 
> Reviewed-by: Aaron Conole 
> ---
>  .travis/linux-build.sh   |   2 +-
>  Documentation/intro/install/dpdk.rst |   8 +-
>  Documentation/topics/dpdk/vhost-user.rst |   8 +-
>  NEWS |   1 +
>  lib/netdev-dpdk.c| 144 
> +++
>  rhel/openvswitch-fedora.spec.in  |   2 +-
>  tests/dpdk/ring_client.c |   6 +-
>  7 files changed, 105 insertions(+), 66 deletions(-)
> 
> diff --git a/.travis/linux-build.sh b/.travis/linux-build.sh
> index f66b534..efccdf1 100755
> --- a/.travis/linux-build.sh
> +++ b/.travis/linux-build.sh
> @@ -80,7 +80,7 @@ fi
>  
>  if [ "$DPDK" ]; then
>  if [ -z "$DPDK_VER" ]; then
> -DPDK_VER="16.11.2"
> +DPDK_VER="17.05.1"
>  fi
>  install_dpdk $DPDK_VER
>  if [ "$CC" = "clang" ]; then
> diff --git a/Documentation/intro/install/dpdk.rst 
> b/Documentation/intro/install/dpdk.rst
> index a05aa1a..4a178f3 100644
> --- a/Documentation/intro/install/dpdk.rst
> +++ b/Documentation/intro/install/dpdk.rst
> @@ -40,7 +40,7 @@ Build requirements
>  In addition to the requirements described in :doc:`general`, building Open
>  vSwitch with DPDK will require the following:
>  
> -- DPDK 16.11
> +- DPDK 17.05.1
>  
>  - A `DPDK supported NIC`_
>  
> @@ -69,9 +69,9 @@ Install DPDK
>  #. Download the `DPDK sources`_, extract the file and set ``DPDK_DIR``::
>  
> $ cd /usr/src/
> -   $ wget http://fast.dpdk.org/rel/dpdk-16.11.2.tar.xz
> -   $ tar xf dpdk-16.11.2.tar.xz
> -   $ export DPDK_DIR=/usr/src/dpdk-stable-16.11.2
> +   $ wget http://fast.dpdk.org/rel/dpdk-17.05.1.tar.xz
> +   $ tar xf dpdk-17.05.1.tar.xz
> +   $ export DPDK_DIR=/usr/src/dpdk-stable-17.05.1
> $ cd $DPDK_DIR
>  
>  #. (Optional) Configure DPDK as a shared library

There is a reference to DPDK16.11 release notes at the end of this file

> diff --git a/Documentation/topics/dpdk/vhost-user.rst 
> b/Documentation/topics/dpdk/vhost-user.rst
> index e76da5f..9f11ea1 100644
> --- a/Documentation/topics/dpdk/vhost-user.rst
> +++ b/Documentation/topics/dpdk/vhost-user.rst
> @@ -292,9 +292,9 @@ To begin, instantiate a guest as described in 
> :ref:`dpdk-vhost-user` or
>  DPDK sources to VM and build DPDK::
>  
>  $ cd /root/dpdk/
> -$ wget http://fast.dpdk.org/rel/dpdk-16.11.2.tar.xz
> -$ tar xf dpdk-16.11.2.tar.xz
> -$ export DPDK_DIR=/root/dpdk/dpdk-stable-16.11.2
> +$ wget http://fast.dpdk.org/rel/dpdk-17.05.1.tar.xz
> +$ tar xf dpdk-17.05.1.tar.xz
> +$ export DPDK_DIR=/root/dpdk/dpdk-stable-17.05.1
>  $ export DPDK_TARGET=x86_64-native-linuxapp-gcc
>  $ export DPDK_BUILD=$DPDK_DIR/$DPDK_TARGET
>  $ cd $DPDK_DIR
> @@ -378,7 +378,7 @@ Sample XML
>  
>  
>
> -  
> +  
>
>
>  

There are references to /tools/dpdk-devbind.py in a few docs, these
should change to /usertools/dpdk-devbind.py

> diff --git a/NEWS b/NEWS
> index d61fc5f..3f58e8b 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -21,6 +21,7 @@ Post-v2.7.0
> still can be configured via extra arguments for DPDK EAL.
>   * dpdkvhostuser ports are marked as deprecated.  They will be removed
> in an upcoming release.
> + * Support for DPDK v17.05.1.

I think you can add into the faq OVS/DPDK table "2.8.x 17.05.1" as part
of this or a follow up patch, if you want to be sure this makes OVS 2.8
first.

> - IPFIX now provides additional counters:
>   * Total counters since metering process startup.
>   * Per-flow TCP flag counters.
> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
> index ea17b97..5e767e1 100644
> --- a/lib/netdev-dpdk.c
> +++ b/lib/netdev-dpdk.c
> @@ -22,6 +22,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  
>  #include 
>  #include 
> @@ -31,7 +34,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  #include "dirs.h"
>  

Re: [ovs-dev] [PATCH 1/4] dpif-netdev: Avoid reading RSS hash when EMC is disabled.

[Fischetti, Antonio]

Hi Billy, your suggestion really simplify the code a lot and improve
readability but unfortunately there's no gain in performance.
Anyway in the next version I'm adding some further change and I will
try to take into account your suggestions.

/Antonio

> -Original Message-
> From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
> boun...@openvswitch.org] On Behalf Of Fischetti, Antonio
> Sent: Friday, June 23, 2017 10:53 PM
> To: O Mahony, Billy ; d...@openvswitch.org
> Subject: Re: [ovs-dev] [PATCH 1/4] dpif-netdev: Avoid reading RSS hash
> when EMC is disabled.
> 
> Hi Billy, thanks for your suggestion, it makes the code more clean
> and readable.
> Once I get back from vacation I'll give it a try and check if this
> still gives a performance benefit.
> 
> /Antonio
> 
> > -Original Message-
> > From: O Mahony, Billy
> > Sent: Friday, June 23, 2017 5:23 PM
> > To: Fischetti, Antonio ;
> d...@openvswitch.org
> > Subject: RE: [ovs-dev] [PATCH 1/4] dpif-netdev: Avoid reading RSS hash
> > when EMC is disabled.
> >
> > Hi Antonio,
> >
> > > -Original Message-
> > > From: Fischetti, Antonio
> > > Sent: Friday, June 23, 2017 3:10 PM
> > > To: O Mahony, Billy ; d...@openvswitch.org
> > > Subject: RE: [ovs-dev] [PATCH 1/4] dpif-netdev: Avoid reading RSS hash
> > > when EMC is disabled.
> > >
> > > Hi Billy,
> > > thanks a lot for you suggestions. Those would really help re-factoring
> > the
> > > code by avoiding duplications.
> > > The thing is that this patch 1/4 is mainly a preparation for the next
> > patch 2/4.
> > > So I did these changes with the next patch 2/4 in mind.
> > >
> > > The final result I meant to achieve in patch 2/4 is the following.
> > > EMC lookup is skipped - not only when EMC is disabled - but also when
> > > (we're processing recirculated packets) && (the EMC is 'enough' full).
> > > The purpose is to avoid EMC thrashing.
> > >
> > > Below is how the code looks like after applying patches 1/4 and 2/4.
> > > Please let me know if you can find some similar optimizations to avoid
> > code
> > > duplications, that would be great.
> > > 
> > > /*
> > >  * EMC lookup is skipped when one or both of the following
> > >  * two cases occurs:
> > >  *
> > >  *   - EMC is disabled.  This is detected from cur_min.
> > >  *
> > >  *   - The EMC occupancy exceeds EMC_FULL_THRESHOLD and the
> > >  * packet to be classified is being recirculated.  When
> this
> > >  * happens also EMC insertions are skipped for
> recirculated
> > >  * packets.  So that EMC is used just to store entries
> which
> > >  * are hit from the 'original' packets.  This way the EMC
> > >  * thrashing is mitigated with a benefit on performance.
> > >  */
> > > if (!md_is_valid) {
> > > pkt_metadata_init(>md, port_no);
> > > miniflow_extract(packet, >mf);  <== this fn must be
> > called after
> > > pkt_metadta_init
> > > /* This is not a recirculated packet. */
> > > if (OVS_LIKELY(cur_min)) {
> > > /* EMC is enabled.  We can retrieve the 5-tuple hash
> > >  * without considering the recirc id. */
> > > if (OVS_LIKELY(dp_packet_rss_valid(packet))) {
> > > key->hash = dp_packet_get_rss_hash(packet);
> > > } else {
> > > key->hash = miniflow_hash_5tuple(>mf, 0);
> > > dp_packet_set_rss_hash(packet, key->hash);
> > > }
> > > flow = emc_lookup(flow_cache, key);
> > > } else {
> > > /* EMC is disabled, skip emc_lookup. */
> > > flow = NULL;
> > > }
> > > } else {
> > > /* Recirculated packets. */
> > > miniflow_extract(packet, >mf);
> > > if (flow_cache->n_entries & EMC_FULL_THRESHOLD) {
> > > /* EMC occupancy is over the threshold.  We skip EMC
> > >  * lookup for recirculated packets. */
> > > flow = NULL;
> > > } else {
> > > if (OVS_LIKELY(cur_min)) {
> > > key->hash =
> dpif_netdev_packet_get_rss_hash(packet,
> > > >mf);
> > > flow = emc_lookup(flow_cache, key);
> > > } else {
> > > flow = NULL;
> > > }
> > > }
> > > }
> > > 
> > >
> > > Basically patch 1/4 is mostly a preliminary change for 2/4.
> > >
> > > Yes, patch 1/4 also allows to avoid reading hash when EMC is disabled.
> > > Or - for packets that are not recirculated - avoids calling
> > > recirc_depth_get_unsafe() when reading the hash.
> > >
> > > Also, as these 

[ovs-dev] [PATCH v2 5/5] dp-packet: Use memcpy on dp_packet elements.

[antonio . fischetti]

memcpy replaces the several single copies inside
dp_packet_clone_with_headroom().

Signed-off-by: Antonio Fischetti 
---
 lib/dp-packet.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/lib/dp-packet.c b/lib/dp-packet.c
index 67aa406..f4dbcb7 100644
--- a/lib/dp-packet.c
+++ b/lib/dp-packet.c
@@ -157,8 +157,9 @@ dp_packet_clone(const struct dp_packet *buffer)
 return dp_packet_clone_with_headroom(buffer, 0);
 }
 
-/* Creates and returns a new dp_packet whose data are copied from 'buffer'.   
The
- * returned dp_packet will additionally have 'headroom' bytes of headroom. */
+/* Creates and returns a new dp_packet whose data are copied from 'buffer'.
+ * The returned dp_packet will additionally have 'headroom' bytes of
+ * headroom. */
 struct dp_packet *
 dp_packet_clone_with_headroom(const struct dp_packet *buffer, size_t headroom)
 {
@@ -167,13 +168,12 @@ dp_packet_clone_with_headroom(const struct dp_packet 
*buffer, size_t headroom)
 new_buffer = dp_packet_clone_data_with_headroom(dp_packet_data(buffer),
  dp_packet_size(buffer),
  headroom);
-new_buffer->l2_pad_size = buffer->l2_pad_size;
-new_buffer->l2_5_ofs = buffer->l2_5_ofs;
-new_buffer->l3_ofs = buffer->l3_ofs;
-new_buffer->l4_ofs = buffer->l4_ofs;
-new_buffer->md = buffer->md;
-new_buffer->cutlen = buffer->cutlen;
-new_buffer->packet_type = buffer->packet_type;
+/* Copy the following fields into the returned buffer: l2_pad_size,
+ * l2_5_ofs, l3_ofs, l4_ofs, cutlen, packet_type and md. */
+memcpy(_buffer->l2_pad_size, >l2_pad_size,
+sizeof(struct dp_packet) -
+offsetof(struct dp_packet, l2_pad_size));
+
 #ifdef DPDK_NETDEV
 new_buffer->mbuf.ol_flags = buffer->mbuf.ol_flags;
 #else
-- 
2.4.11

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

[ovs-dev] [PATCH v2 4/5] conntrack: pass current time to conntrack_execute.

[antonio . fischetti]

Current time is passed to conntrack_execute so it doesn't have
to recompute it again.

Signed-off-by: Antonio Fischetti 
Acked by: Sugesh Chandran 
---
In a firewall testbench set up with

 table=0, priority=1 actions=drop
 table=0, priority=10,arp actions=NORMAL
 table=0, priority=100,ct_state=-trk,ip actions=ct(table=1)
 table=1, ct_state=+new+trk,ip,in_port=1 actions=ct(commit),output:2
 table=1, ct_state=+est+trk,ip,in_port=1 actions=output:2
 table=1, ct_state=+new+trk,ip,in_port=2 actions=drop
 table=1, ct_state=+est+trk,ip,in_port=2 actions=output:1

I saw the following performance improvement.

I measured packet Rx rate (regardless of packet loss). Bidirectional
test with 64B UDP packets.

+---++
| Orig OvS-DPDK +   | Previous case  |
| patches #1,2,3| + this patch   |
 ---+---++
 10 UDP connections |   2.60, 2.64  |   2.62, 2.66   |
 ---+---++

 lib/conntrack.c| 4 ++--
 lib/conntrack.h| 3 ++-
 lib/dpif-netdev.c  | 2 +-
 tests/test-conntrack.c | 8 +---
 4 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/lib/conntrack.c b/lib/conntrack.c
index de46a6b..a6ccf2e 100644
--- a/lib/conntrack.c
+++ b/lib/conntrack.c
@@ -840,11 +840,11 @@ conntrack_execute(struct conntrack *ct, struct 
dp_packet_batch *pkt_batch,
   const uint32_t *setmark,
   const struct ovs_key_ct_labels *setlabel,
   const char *helper,
-  const struct nat_action_info_t *nat_action_info)
+  const struct nat_action_info_t *nat_action_info,
+  long long now)
 {
 struct dp_packet **pkts = pkt_batch->packets;
 size_t cnt = pkt_batch->count;
-long long now = time_msec();
 struct conn_lookup_ctx ctx;
 
 if (helper) {
diff --git a/lib/conntrack.h b/lib/conntrack.h
index defde4c..53d0f22 100644
--- a/lib/conntrack.h
+++ b/lib/conntrack.h
@@ -95,7 +95,8 @@ int conntrack_execute(struct conntrack *, struct 
dp_packet_batch *,
   uint16_t zone, const uint32_t *setmark,
   const struct ovs_key_ct_labels *setlabel,
   const char *helper,
-  const struct nat_action_info_t *nat_action_info);
+  const struct nat_action_info_t *nat_action_info,
+  long long now);
 
 struct conntrack_dump {
 struct conntrack *ct;
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 79efce6..8c776ff 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -5384,7 +5384,7 @@ dp_execute_cb(void *aux_, struct dp_packet_batch 
*packets_,
 
 conntrack_execute(>conntrack, packets_, aux->flow->dl_type, force,
   commit, zone, setmark, setlabel, helper,
-  nat_action_info_ref);
+  nat_action_info_ref, now);
 break;
 }
 
diff --git a/tests/test-conntrack.c b/tests/test-conntrack.c
index 6a77db8..b27d181 100644
--- a/tests/test-conntrack.c
+++ b/tests/test-conntrack.c
@@ -84,12 +84,13 @@ ct_thread_main(void *aux_)
 struct dp_packet_batch *pkt_batch;
 ovs_be16 dl_type;
 size_t i;
+long long now = time_msec();
 
 pkt_batch = prepare_packets(batch_size, change_conn, aux->tid, _type);
 ovs_barrier_block();
 for (i = 0; i < n_pkts; i += batch_size) {
 conntrack_execute(, pkt_batch, dl_type, false, true, 0, NULL, NULL,
-  NULL, NULL);
+  NULL, NULL, now);
 }
 ovs_barrier_block();
 destroy_packets(pkt_batch);
@@ -154,6 +155,7 @@ pcap_batch_execute_conntrack(struct conntrack *ct,
 {
 struct dp_packet_batch new_batch;
 ovs_be16 dl_type = htons(0);
+long long now = time_msec();
 
 dp_packet_batch_init(_batch);
 
@@ -172,7 +174,7 @@ pcap_batch_execute_conntrack(struct conntrack *ct,
 
 if (flow.dl_type != dl_type) {
 conntrack_execute(ct, _batch, dl_type, false, true, 0,
-  NULL, NULL, NULL, NULL);
+  NULL, NULL, NULL, NULL, now);
 dp_packet_batch_init(_batch);
 }
 new_batch.packets[new_batch.count++] = packet;;
@@ -180,7 +182,7 @@ pcap_batch_execute_conntrack(struct conntrack *ct,
 
 if (!dp_packet_batch_is_empty(_batch)) {
 conntrack_execute(ct, _batch, dl_type, false, true, 0, NULL, NULL,
-  NULL, NULL);
+  NULL, NULL, now);
 }
 
 }
-- 
2.4.11

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

[ovs-dev] [PATCH v2 3/5] dpif-netdev: Skip EMC lookup/insert for recirc packets.

[antonio . fischetti]

When OVS is configured as a firewall, with thousands of active
concurrent connections, the EMC gets quicly saturated and may come under
heavy thrashing for the reason that original and recirculated packets
keep overwrite existing active EMC entries due to its limited size (8k).

This thrashing causes the EMC to be less efficient than the dcpls in
terms of lookups and insertions.

This patch allows to use the EMC efficiently by allowing only the 'original'
packets to hit EMC. All recirculated packets are sent to the classifier 
directly.
An empirical threshold (EMC_RECIRCT_NO_INSERT_THRESHOLD - of 50%) for EMC
occupancy is set to trigger this logic. By doing so when EMC utilization exceeds
EMC_RECIRCT_NO_INSERT_THRESHOLD:
 - EMC Insertions are allowed just for original packets. EMC insertion
   and look up is skipped for recirculated packets.
 - Recirculated packets are sent to the classifier.

This patch is based on patch
"dpif-netdev: add EMC entry count and %full figure to pmd-stats-show" at:
https://mail.openvswitch.org/pipermail/ovs-dev/2017-January/327570.html
Also, this patch depends on the previous one in this series.

Signed-off-by: Antonio Fischetti 
Signed-off-by: Bhanuprakash Bodireddy 
Co-authored-by: Bhanuprakash Bodireddy 
---
In our Connection Tracker testbench set up with

 table=0, priority=1 actions=drop
 table=0, priority=10,arp actions=NORMAL
 table=0, priority=100,ct_state=-trk,ip actions=ct(table=1)
 table=1, ct_state=+new+trk,ip,in_port=1 actions=ct(commit),output:2
 table=1, ct_state=+est+trk,ip,in_port=1 actions=output:2
 table=1, ct_state=+new+trk,ip,in_port=2 actions=drop
 table=1, ct_state=+est+trk,ip,in_port=2 actions=output:1

we saw the following performance improvement.

We measured packet Rx rate (regardless of packet loss). Bidirectional
test with 64B UDP packets.
Each row is a test with a different number of traffic streams. The traffic
generator is set so that each stream establishes one UDP connection.
Mpps columns reports the Rx rates on the 2 sides.

  +--+---+
  |  Original OvS-DPDK   |Previous case  |
  |  + patches #1,2  |+ this patch   |
 -++-++--+
  Traffic | Rx |   EMC   | Rx |   EMC|
  Streams |   [Mpps]   | entries |   [Mpps]   | entries  |
 -++-++--+
  10  | 2.60, 2.67 |20   | 2.60, 2.64 |20|
 100  | 2.53, 2.58 |   200   | 2.59, 2.61 |   201| 
   1,000  | 2.02, 2.03 |  1929   | 2.15, 2.15 |  1997|
   2,000  | 1.94, 1.96 |  3661   | 1.97, 1.98 |  3668|
   3,000  | 1.87, 1.90 |  5086   | 1.96, 1.98 |  4736|
   4,000  | 1.82, 1.82 |  6173   | 1.95, 1.94 |  5280|
  10,000  | 1.68, 1.69 |  7826   | 1.84, 1.84 |  7102| 
  30,000  | 1.57, 1.58 |  8192   | 1.68, 1.70 |  8192| 
 -++-++--+

This test setup implies 1 recirculation on each received packet.
We didn't check this patch in a test scenario where more than 1
recirculation is occurring per packet.

 lib/dpif-netdev.c | 63 ++-
 1 file changed, 58 insertions(+), 5 deletions(-)

diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 9562827..79efce6 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -4573,6 +4573,9 @@ dp_netdev_queue_batches(struct dp_packet *pkt,
 packet_batch_per_flow_update(batch, pkt, mf);
 }
 
+/* Threshold to skip EMC for recirculated packets. */
+#define EMC_RECIRCT_NO_INSERT_THRESHOLD 0xF000
+
 /* Try to process all ('cnt') the 'packets' using only the exact match cache
  * 'pmd->flow_cache'. If a flow is not found for a packet 'packets[i]', the
  * miniflow is copied into 'keys' and the packet pointer is moved at the
@@ -4620,15 +4623,39 @@ emc_processing(struct dp_netdev_pmd_thread *pmd,
 miniflow_extract(packet, >mf);
 key->len = 0; /* Not computed yet. */
 
-/* If EMC is disabled skip hash computation and emc_lookup */
+/*
+ * EMC lookup is skipped when one or both of the following
+ * two cases occurs:
+ *
+ *   - EMC is disabled.  This is detected from cur_min.
+ *
+ *   - The EMC occupancy exceeds EMC_RECIRCT_NO_INSERT_THRESHOLD and
+ * the packet to be classified is being recirculated.  When this
+ * happens also EMC insertions are skipped for recirculated
+ * packets.  So that EMC is used just to store entries which
+ * are hit from the 'original' packets.  This way the EMC
+ * thrashing is mitigated with a benefit on performance.
+ */
 if (OVS_LIKELY(cur_min)) {
 if (!md_is_valid) {
+/* This is an original packet.  As it is not 

[ovs-dev] [PATCH v2 2/5] dpif-netdev: Avoid reading RSS hash when EMC is disabled.

[antonio . fischetti]

When EMC is disabled the reading of RSS hash is skipped.
For packets that are not recirculated it retrieves the hash
value without considering the recirc id.

This is mostly a preliminary change for the next patch in
this series.

Signed-off-by: Antonio Fischetti 
---
 lib/dpif-netdev.c | 42 ++
 1 file changed, 34 insertions(+), 8 deletions(-)

diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 123e04a..9562827 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -4472,6 +4472,22 @@ dp_netdev_upcall(struct dp_netdev_pmd_thread *pmd, 
struct dp_packet *packet_,
 }
 
 static inline uint32_t
+dpif_netdev_packet_get_rss_hash_orig_pkt(struct dp_packet *packet,
+const struct miniflow *mf)
+{
+uint32_t hash;
+
+if (OVS_LIKELY(dp_packet_rss_valid(packet))) {
+hash = dp_packet_get_rss_hash(packet);
+} else {
+hash = miniflow_hash_5tuple(mf, 0);
+dp_packet_set_rss_hash(packet, hash);
+}
+
+return hash;
+}
+
+static inline uint32_t
 dpif_netdev_packet_get_rss_hash(struct dp_packet *packet,
 const struct miniflow *mf)
 {
@@ -4572,7 +4588,8 @@ static inline size_t
 emc_processing(struct dp_netdev_pmd_thread *pmd,
struct dp_packet_batch *packets_,
struct netdev_flow_key *keys,
-   struct packet_batch_per_flow batches[], size_t *n_batches)
+   struct packet_batch_per_flow batches[], size_t *n_batches,
+   bool md_is_valid)
 {
 struct emc_cache *flow_cache = >flow_cache;
 struct netdev_flow_key *key = [0];
@@ -4602,10 +4619,19 @@ emc_processing(struct dp_netdev_pmd_thread *pmd,
 
 miniflow_extract(packet, >mf);
 key->len = 0; /* Not computed yet. */
-key->hash = dpif_netdev_packet_get_rss_hash(packet, >mf);
 
-/* If EMC is disabled skip emc_lookup */
-flow = (cur_min == 0) ? NULL: emc_lookup(flow_cache, key);
+/* If EMC is disabled skip hash computation and emc_lookup */
+if (OVS_LIKELY(cur_min)) {
+if (!md_is_valid) {
+key->hash = dpif_netdev_packet_get_rss_hash_orig_pkt(packet,
+>mf);
+} else {
+key->hash = dpif_netdev_packet_get_rss_hash(packet, >mf);
+}
+flow = emc_lookup(flow_cache, key);
+} else {
+flow = NULL;
+}
 if (OVS_LIKELY(flow)) {
 dp_netdev_queue_batches(packet, flow, >mf, batches,
 n_batches);
@@ -4801,7 +4827,7 @@ fast_path_processing(struct dp_netdev_pmd_thread *pmd,
  * valid, 'md_is_valid' must be true and 'port_no' will be ignored. */
 static void
 dp_netdev_input__(struct dp_netdev_pmd_thread *pmd,
-  struct dp_packet_batch *packets)
+  struct dp_packet_batch *packets, bool md_is_valid)
 {
 int cnt = packets->count;
 #if !defined(__CHECKER__) && !defined(_WIN32)
@@ -4818,7 +4844,7 @@ dp_netdev_input__(struct dp_netdev_pmd_thread *pmd,
 odp_port_t in_port;
 
 n_batches = 0;
-emc_processing(pmd, packets, keys, batches, _batches);
+emc_processing(pmd, packets, keys, batches, _batches, md_is_valid);
 if (!dp_packet_batch_is_empty(packets)) {
 /* Get ingress port from first packet's metadata. */
 in_port = packets->packets[0]->md.in_port.odp_port;
@@ -4855,14 +4881,14 @@ dp_netdev_input(struct dp_netdev_pmd_thread *pmd,
 pkt_metadata_init(>md, port_no);
 }
 
-dp_netdev_input__(pmd, packets);
+dp_netdev_input__(pmd, packets, false);
 }
 
 static void
 dp_netdev_recirculate(struct dp_netdev_pmd_thread *pmd,
   struct dp_packet_batch *packets)
 {
-dp_netdev_input__(pmd, packets);
+dp_netdev_input__(pmd, packets, true);
 }
 
 struct dp_netdev_execute_aux {
-- 
2.4.11

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

[ovs-dev] [PATCH v2 1/5] dpif-netdev: move pkt metadata init out of emc_processing.

[antonio . fischetti]

Packet metadata initialization is moved into dp_netdev_input to improve
performance.

Signed-off-by: Antonio Fischetti 
---
In my testbench with the following port to port flow setup:
in_port=1,action=output:2
in_port=2,action=output:1

I measured packet Rx rate (regardless of packet loss) in a Bidirectional test
with  64B UDP packets.

I saw the following performance improvement 

Orig:  11.30, 11.54 Mpps
Orig + patch:  11.70, 11.76 Mpps

 lib/dpif-netdev.c | 21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 98e7765..123e04a 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -4572,8 +4572,7 @@ static inline size_t
 emc_processing(struct dp_netdev_pmd_thread *pmd,
struct dp_packet_batch *packets_,
struct netdev_flow_key *keys,
-   struct packet_batch_per_flow batches[], size_t *n_batches,
-   bool md_is_valid, odp_port_t port_no)
+   struct packet_batch_per_flow batches[], size_t *n_batches)
 {
 struct emc_cache *flow_cache = >flow_cache;
 struct netdev_flow_key *key = [0];
@@ -4601,9 +4600,6 @@ emc_processing(struct dp_netdev_pmd_thread *pmd,
 pkt_metadata_prefetch_init([i+1]->md);
 }
 
-if (!md_is_valid) {
-pkt_metadata_init(>md, port_no);
-}
 miniflow_extract(packet, >mf);
 key->len = 0; /* Not computed yet. */
 key->hash = dpif_netdev_packet_get_rss_hash(packet, >mf);
@@ -4805,8 +4801,7 @@ fast_path_processing(struct dp_netdev_pmd_thread *pmd,
  * valid, 'md_is_valid' must be true and 'port_no' will be ignored. */
 static void
 dp_netdev_input__(struct dp_netdev_pmd_thread *pmd,
-  struct dp_packet_batch *packets,
-  bool md_is_valid, odp_port_t port_no)
+  struct dp_packet_batch *packets)
 {
 int cnt = packets->count;
 #if !defined(__CHECKER__) && !defined(_WIN32)
@@ -4823,8 +4818,7 @@ dp_netdev_input__(struct dp_netdev_pmd_thread *pmd,
 odp_port_t in_port;
 
 n_batches = 0;
-emc_processing(pmd, packets, keys, batches, _batches,
-md_is_valid, port_no);
+emc_processing(pmd, packets, keys, batches, _batches);
 if (!dp_packet_batch_is_empty(packets)) {
 /* Get ingress port from first packet's metadata. */
 in_port = packets->packets[0]->md.in_port.odp_port;
@@ -4856,14 +4850,19 @@ dp_netdev_input(struct dp_netdev_pmd_thread *pmd,
 struct dp_packet_batch *packets,
 odp_port_t port_no)
 {
-dp_netdev_input__(pmd, packets, false, port_no);
+struct dp_packet *packet;
+DP_PACKET_BATCH_FOR_EACH (packet, packets) {
+pkt_metadata_init(>md, port_no);
+}
+
+dp_netdev_input__(pmd, packets);
 }
 
 static void
 dp_netdev_recirculate(struct dp_netdev_pmd_thread *pmd,
   struct dp_packet_batch *packets)
 {
-dp_netdev_input__(pmd, packets, true, 0);
+dp_netdev_input__(pmd, packets);
 }
 
 struct dp_netdev_execute_aux {
-- 
2.4.11

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

Re: [ovs-dev] [PATCH 1/2] dpif-netlink: Use netlink helpers for packet_type.

[Eric Garver]

On Tue, Jul 18, 2017 at 03:32:43PM -0700, Joe Stringer wrote:
> Rather than open-coding access to netlink attribute pointers in
> put_exclude_packet_type(), make use of the netlink attribute helpers.
> This simplifies the following bugfix.
> 
> Signed-off-by: Joe Stringer 
> ---
>  lib/dpif-netlink.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
> index 562f6134c3a5..63ef3de5c7d1 100644
> --- a/lib/dpif-netlink.c
> +++ b/lib/dpif-netlink.c
> @@ -3452,13 +3452,13 @@ put_exclude_packet_type(struct ofpbuf *buf, uint16_t 
> type,
>  size_t first_chunk_size = (uint8_t *)packet_type - (uint8_t *)data;
>  size_t second_chunk_size = data_len - first_chunk_size
> - packet_type_len;
> -uint8_t *first_attr = NULL;
>  struct nlattr *next_attr = nl_attr_next(packet_type);
> +size_t ofs;
>  
> -first_attr = nl_msg_put_unspec_uninit(buf, type,
> -  data_len - packet_type_len);
> -memcpy(first_attr, data, first_chunk_size);
> -memcpy(first_attr + first_chunk_size, next_attr, second_chunk_size);
> +ofs = nl_msg_start_nested(buf, type);
> +nl_msg_put(buf, data, first_chunk_size);
> +nl_msg_put(buf, next_attr, second_chunk_size);
> +nl_msg_end_nested(buf, ofs);
>  } else {
>  nl_msg_put_unspec(buf, type, data, data_len);
>  }
> -- 
> 2.11.1
> 

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

Re: [ovs-dev] [PATCH 2/2] dpif-netlink: For non-Ethernet, use Ethertype from packet_type.

[Eric Garver]

On Tue, Jul 18, 2017 at 03:32:44PM -0700, Joe Stringer wrote:
> For non-Ethernet flows, when fixing up the netlink message we need make
> sure to pass down a valid Ethertype. The kernel does not understand
> packet_type so it's implicitly encoded by the absence of _ETHERNET and
> exact match of _ETHERTYPE. Without this change match_validate in the
> kernel complains when trying to match packets from L3 tunnels.
> e.g.
>   openvswitch: netlink: Unexpected mask (mask=110088, allowed=3d9804c)
> 
> The mask use to always be set in xlate_wc_init() and xlate_wc_finish(),
> but that changed for non-Ethernet frames with the commit listed below.
> 
> Fixes: 3d4b2e6eb74e ("userspace: Add OXM field MFF_PACKET_TYPE")
> Signed-off-by: Joe Stringer 
> Co-authored-by: Eric Garver 
> ---
>  lib/dpif-netlink.c | 19 +--
>  1 file changed, 17 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
> index 63ef3de5c7d1..55effd1f91a8 100644
> --- a/lib/dpif-netlink.c
> +++ b/lib/dpif-netlink.c
> @@ -3434,8 +3434,9 @@ dpif_netlink_flow_from_ofpbuf(struct dpif_netlink_flow 
> *flow,
>  
>  
>  /*
> - * If PACKET_TYPE attribute is present in 'data', it filters PACKET_TYPE out,
> - * then puts 'data' to 'buf'.
> + * If PACKET_TYPE attribute is present in 'data', it filters PACKET_TYPE out.
> + * If the flow is not Ethernet, the OVS_KEY_ATTR_PACKET_TYPE is converted to
> + * OVS_KEY_ATTR_ETHERTYPE. Puts 'data' to 'buf'.
>   */
>  static void
>  put_exclude_packet_type(struct ofpbuf *buf, uint16_t type,
> @@ -3458,6 +3459,20 @@ put_exclude_packet_type(struct ofpbuf *buf, uint16_t 
> type,
>  ofs = nl_msg_start_nested(buf, type);
>  nl_msg_put(buf, data, first_chunk_size);
>  nl_msg_put(buf, next_attr, second_chunk_size);
> +if (!nl_attr_find__(data, data_len, OVS_KEY_ATTR_ETHERNET)) {
> +ovs_be16 pt = pt_ns_type_be(nl_attr_get_be32(packet_type));
> +const struct nlattr *nla;
> +
> +nla = nl_attr_find(buf, NLA_HDRLEN, OVS_KEY_ATTR_ETHERTYPE);
> +if (nla) {
> +ovs_be16 *ethertype;
> +
> +ethertype = CONST_CAST(ovs_be16 *, nl_attr_get(nla));
> +*ethertype = pt;
> +} else {
> +nl_msg_put_be16(buf, OVS_KEY_ATTR_ETHERTYPE, pt);
> +}
> +}
>  nl_msg_end_nested(buf, ofs);
>  } else {
>  nl_msg_put_unspec(buf, type, data, data_len);
> -- 
> 2.11.1
> 

Thanks Joe! This is definitely more concise than my version.

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

[ovs-dev] Debugging on openvswitch source code

[NOUGNANKE KOKOUVI BENOIT]

I am trying to understand the openvswitch source code, in order to
customize some treatments.

For example, I would like, when a packet is received on the OVS bridge, to
know all the functions that are called and the processing that the packet
undergoes.
So I added VLOG_DBG ("") in some functions. After configuring the Vlog
with (ovs-appctl vlog / set ..) and checking the log files I do not see any
of my VLOG_DBG messages.

So I would like to know if one could help me on this subject or propose me
methods that are used for debugging when modifying the source code of OVS,
like doing debugging with "printf" in a  source code.

Thank you

Benoit Nougnanke


Garanti
sans virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 2/2] dpif-netdev: Indicate support for various ct features.

[Justin Pettit]

> On Jul 19, 2017, at 2:45 AM, Darrell Ball  wrote:
> 
> This change does not seem to be all that useful.
> 
> When rules are constructed, mask and action support do check previously 
> probed support
> which will be ‘TRUE’.
> 
> Another way to see that the below settings are not useful is to set 
> everything to ‘false’ (see below) and run all
> the system tests in userspace, which will all pass.

This change does affect behavior.  For example, upcall debug log messages will 
now show ct_orig_tuple members.  The reason is that dp_netdev_upcall() passes 
those support parameters to odp_flow_key_from_flow(), which thinks that the 
datapath doesn't support those features, so it doesn't print the values.

> By the way, the .max_vlan_headers and .max_mpls_headers fields, which I did 
> not change are pretty big
> numbers and I am fairly sure OVS does not really support that many vlans and 
> labels.
> 
> static struct odp_support dp_netdev_support = {
>.max_vlan_headers = SIZE_MAX,
>.max_mpls_depth = SIZE_MAX,
>.recirc = false,
>.ct_state = false,
>.ct_zone = false,
>.ct_mark = false,
>.ct_label = false,
>.ct_state_nat = false,
>.ct_orig_tuple = false,
>.ct_orig_tuple6 = false,
> };
> 
> I think it may be better to clean this up. I can do this if you are ok with 
> that; either way is fine with me.

I agree that since the datapath features are probed, we should pass those 
parameters around instead of using these hardcoded values.  However, it was a 
more invasive change than I wanted to make at the time, and I'd want to apply 
this fix regardless.  I was going to add using the probed values to my to-do 
list, but I'm happy if you want to take it.

Thanks,

--Justin


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

[ovs-dev] [PATCH 3/3] dpif-netdev.at: Add netdev-dummy/receive test.

[Ilya Maximets]

Regression test for 'netdev-dummy/receive' appctl command.

Signed-off-by: Ilya Maximets 
---
 tests/dpif-netdev.at | 21 +
 1 file changed, 21 insertions(+)

diff --git a/tests/dpif-netdev.at b/tests/dpif-netdev.at
index a526b85..c6f6a66 100644
--- a/tests/dpif-netdev.at
+++ b/tests/dpif-netdev.at
@@ -47,6 +47,27 @@ strip_metadata () {
 ]
 m4_divert_pop([PREPARE_TESTS])
 
+AT_SETUP([dpif-netdev - netdev-dummy/receive])
+# Create br0 with interfaces p0
+OVS_VSWITCHD_START([add-port br0 p1 -- set interface p1 type=dummy 
ofport_request=1 -- ])
+AT_CHECK([ovs-appctl vlog/set dpif:dbg dpif_netdev:dbg])
+
+AT_CHECK([ovs-ofctl add-flow br0 action=normal])
+ovs-appctl time/stop
+ovs-appctl time/warp 5000
+AT_CHECK([ovs-appctl netdev-dummy/receive p1 
'in_port(1),eth(src=50:54:00:00:00:01,dst=50:54:00:00:02:00),eth_type(0x0800),ipv4(src=10.0.0.1,dst=10.0.0.2,proto=6,tos=0,ttl=64,frag=no),tcp(src=8,dst=9),tcp_flags(ack)'])
+   AT_CHECK([grep -A 1 'miss upcall' ovs-vswitchd.log | tail -n 1], [0], [dnl
+skb_priority(0),skb_mark(0),ct_state(0),ct_zone(0),ct_mark(0),ct_label(0),recirc_id(0),dp_hash(0),in_port(1),packet_type(ns=0,id=0),eth(src=50:54:00:00:00:01,dst=50:54:00:00:02:00),eth_type(0x0800),ipv4(src=10.0.0.1,dst=10.0.0.2,proto=6,tos=0,ttl=64,frag=no),tcp(src=8,dst=9),tcp_flags(ack)
+])
+
+AT_CHECK([ovs-appctl netdev-dummy/receive p1 
'in_port(1),eth(src=50:54:00:00:00:05,dst=50:54:00:00:06:00),eth_type(0x0800),ipv4(src=10.0.0.5,dst=10.0.0.6,proto=6,tos=0,ttl=64,frag=no),tcp(src=8,dst=9),tcp_flags(ack)'
 --len 1024])
+   AT_CHECK([grep -A 1 'miss upcall' ovs-vswitchd.log | tail -n 1], [0], [dnl
+skb_priority(0),skb_mark(0),ct_state(0),ct_zone(0),ct_mark(0),ct_label(0),recirc_id(0),dp_hash(0),in_port(1),packet_type(ns=0,id=0),eth(src=50:54:00:00:00:05,dst=50:54:00:00:06:00),eth_type(0x0800),ipv4(src=10.0.0.5,dst=10.0.0.6,proto=6,tos=0,ttl=64,frag=no),tcp(src=8,dst=9),tcp_flags(ack)
+])
+OVS_VSWITCHD_STOP
+AT_CLEANUP
+
+
 m4_define([DPIF_NETDEV_DUMMY_IFACE],
   [AT_SETUP([dpif-netdev - $1 interface])
# Create br0 with interfaces p1 and p7
-- 
2.7.4

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

[ovs-dev] [PATCH 2/3] netdev-dummy: Fix setting length in recieve command.

[Ilya Maximets]

Currently, if '--len' option passed to 'netdev-dummy/receive' command,
only 'size' field of dp_packet will changes.

This is incorrect behaviour, because memory for that size is not
allocated and also packet headers not fixed to reflect the new size.
This leads to flow_extract() failure, because it checks the
'ip->tot_len' and stops further parsing if it doesn't match the
dp_packet_size(). As a result packets created while processing of the
'receive' command can't be parsed to the same flow.
Additionally this may lead to wrong memory accesses in case someone
will try to read or modify packets data.

Fix that by creating right packets using recently introduced option
'packet_size' for 'flow_compose()'.

CC: Andy Zhou 
Fixes: d8ada2368cbe ("netdev-dummy: Add --len option for netdev-dummy/receive 
command")
Signed-off-by: Ilya Maximets 
---
 lib/netdev-dummy.c | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/lib/netdev-dummy.c b/lib/netdev-dummy.c
index 6ee6a6a..481a7d7 100644
--- a/lib/netdev-dummy.c
+++ b/lib/netdev-dummy.c
@@ -1449,7 +1449,7 @@ eth_from_packet(const char *s)
 }
 
 static struct dp_packet *
-eth_from_flow(const char *s)
+eth_from_flow(const char *s, size_t packet_size)
 {
 enum odp_key_fitness fitness;
 struct dp_packet *packet;
@@ -1478,7 +1478,7 @@ eth_from_flow(const char *s)
 }
 
 packet = dp_packet_new(0);
-flow_compose(packet, , 0);
+flow_compose(packet, , packet_size);
 
 ofpbuf_uninit(_key);
 return packet;
@@ -1556,20 +1556,26 @@ netdev_dummy_receive(struct unixctl_conn *conn,
 packet = eth_from_packet(argv[i]);
 
 if (!packet) {
+int packet_size = 0;
+const char *flow_str = argv[i];
+
+/* Parse optional --len argument immediately follows a 'flow'.  */
+if (argc >= i + 2 && !strcmp(argv[i + 1], "--len")) {
+packet_size = strtol(argv[i + 2], NULL, 10);
+
+if (packet_size < ETH_TOTAL_MIN) {
+unixctl_command_reply_error(conn, "too small packet len");
+goto exit;
+}
+i+=2;
+}
 /* Try parse 'argv[i]' as odp flow. */
-packet = eth_from_flow(argv[i]);
+packet = eth_from_flow(flow_str, packet_size);
 
 if (!packet) {
 unixctl_command_reply_error(conn, "bad packet or flow syntax");
 goto exit;
 }
-
-/* Parse optional --len argument immediately follows a 'flow'.  */
-if (argc >= i + 2 && !strcmp(argv[i + 1], "--len")) {
-int packet_size = strtol(argv[i + 2], NULL, 10);
-dp_packet_set_size(packet, packet_size);
-i+=2;
-}
 }
 
 netdev_dummy_queue_packet(dummy_dev, packet, rx_qid);
-- 
2.7.4

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

[ovs-dev] [PATCH 1/3] flow: Add packet_size option to flow_compose.

[Ilya Maximets]

This allows to compose packets with different real lenghts from
odp flows i.e. memory will be allocated for requested packet
size and all required headers like ip->tot_len filled correctly.

Will be used in netdev-dummy to properly handle '--len' option.

Signed-off-by: Ilya Maximets 
---
 lib/flow.c   | 65 ++--
 lib/flow.h   |  2 +-
 lib/netdev-dummy.c   |  2 +-
 ofproto/ofproto-dpif-trace.c |  2 +-
 ofproto/ofproto-dpif.c   |  2 +-
 ovn/controller/ofctrl.c  |  2 +-
 tests/test-ovn.c |  2 +-
 7 files changed, 51 insertions(+), 26 deletions(-)

diff --git a/lib/flow.c b/lib/flow.c
index e1597fa..fd0fac4 100644
--- a/lib/flow.c
+++ b/lib/flow.c
@@ -2613,16 +2613,14 @@ flow_set_mpls_lse(struct flow *flow, int idx, ovs_be32 
lse)
 }
 
 static size_t
-flow_compose_l4(struct dp_packet *p, const struct flow *flow)
+flow_compose_l4(struct dp_packet *p, const struct flow *flow, size_t l4_len)
 {
-size_t l4_len = 0;
-
 if (!(flow->nw_frag & FLOW_NW_FRAG_ANY)
 || !(flow->nw_frag & FLOW_NW_FRAG_LATER)) {
 if (flow->nw_proto == IPPROTO_TCP) {
 struct tcp_header *tcp;
 
-l4_len = sizeof *tcp;
+l4_len = MAX(l4_len, sizeof *tcp);
 tcp = dp_packet_put_zeros(p, l4_len);
 tcp->tcp_src = flow->tp_src;
 tcp->tcp_dst = flow->tp_dst;
@@ -2630,7 +2628,7 @@ flow_compose_l4(struct dp_packet *p, const struct flow 
*flow)
 } else if (flow->nw_proto == IPPROTO_UDP) {
 struct udp_header *udp;
 
-l4_len = sizeof *udp;
+l4_len = MAX(l4_len, sizeof *udp);
 udp = dp_packet_put_zeros(p, l4_len);
 udp->udp_src = flow->tp_src;
 udp->udp_dst = flow->tp_dst;
@@ -2638,30 +2636,31 @@ flow_compose_l4(struct dp_packet *p, const struct flow 
*flow)
 } else if (flow->nw_proto == IPPROTO_SCTP) {
 struct sctp_header *sctp;
 
-l4_len = sizeof *sctp;
+l4_len = MAX(l4_len, sizeof *sctp);
 sctp = dp_packet_put_zeros(p, l4_len);
 sctp->sctp_src = flow->tp_src;
 sctp->sctp_dst = flow->tp_dst;
 } else if (flow->nw_proto == IPPROTO_ICMP) {
 struct icmp_header *icmp;
 
-l4_len = sizeof *icmp;
+l4_len = MAX(l4_len, sizeof *icmp);
 icmp = dp_packet_put_zeros(p, l4_len);
 icmp->icmp_type = ntohs(flow->tp_src);
 icmp->icmp_code = ntohs(flow->tp_dst);
 } else if (flow->nw_proto == IPPROTO_IGMP) {
 struct igmp_header *igmp;
 
-l4_len = sizeof *igmp;
+l4_len = MAX(l4_len, sizeof *igmp);
 igmp = dp_packet_put_zeros(p, l4_len);
 igmp->igmp_type = ntohs(flow->tp_src);
 igmp->igmp_code = ntohs(flow->tp_dst);
 put_16aligned_be32(>group, flow->igmp_group_ip4);
 } else if (flow->nw_proto == IPPROTO_ICMPV6) {
 struct icmp6_hdr *icmp;
+size_t icmpv6_len;
 
-l4_len = sizeof *icmp;
-icmp = dp_packet_put_zeros(p, l4_len);
+icmpv6_len = sizeof *icmp;
+icmp = dp_packet_put_zeros(p, icmpv6_len);
 icmp->icmp6_type = ntohs(flow->tp_src);
 icmp->icmp6_code = ntohs(flow->tp_dst);
 
@@ -2671,26 +2670,33 @@ flow_compose_l4(struct dp_packet *p, const struct flow 
*flow)
 struct in6_addr *nd_target;
 struct ovs_nd_lla_opt *lla_opt;
 
-l4_len += sizeof *nd_target;
+icmpv6_len += sizeof *nd_target;
 nd_target = dp_packet_put_zeros(p, sizeof *nd_target);
 *nd_target = flow->nd_target;
 
 if (!eth_addr_is_zero(flow->arp_sha)) {
-l4_len += 8;
+icmpv6_len += 8;
 lla_opt = dp_packet_put_zeros(p, 8);
 lla_opt->len = 1;
 lla_opt->type = ND_OPT_SOURCE_LINKADDR;
 lla_opt->mac = flow->arp_sha;
 }
 if (!eth_addr_is_zero(flow->arp_tha)) {
-l4_len += 8;
+icmpv6_len += 8;
 lla_opt = dp_packet_put_zeros(p, 8);
 lla_opt->len = 1;
 lla_opt->type = ND_OPT_TARGET_LINKADDR;
 lla_opt->mac = flow->arp_tha;
 }
 }
+if (icmpv6_len < l4_len) {
+dp_packet_put_zeros(p, l4_len - icmpv6_len);
+} else {
+l4_len = icmpv6_len;
+}
 }
+} else {
+ dp_packet_put_zeros(p, l4_len);
 }
 return l4_len;
 }
@@ -2741,20 +2747,28 @@ flow_compose_l4_csum(struct dp_packet *p, const struct 
flow *flow,
 }
 
 /* Puts into 'p' a packet that flow_extract() would parse as having the given
- * 'flow'.

[ovs-dev] [PATCH 0/3] Fix '--len' option for netdev-dummy/receive.

[Ilya Maximets]

See bug details is in patch #2.
First patch introduces changes to 'flow_compose()' which is used
to fix bug in the second patch.
To trigger the issue unit test from patch #3 can be used.

Ilya Maximets (3):
  flow: Add packet_size option to flow_compose.
  netdev-dummy: Fix setting length in recieve command.
  dpif-netdev.at: Add netdev-dummy/receive test.

 lib/flow.c   | 65 ++--
 lib/flow.h   |  2 +-
 lib/netdev-dummy.c   | 26 +++---
 ofproto/ofproto-dpif-trace.c |  2 +-
 ofproto/ofproto-dpif.c   |  2 +-
 ovn/controller/ofctrl.c  |  2 +-
 tests/dpif-netdev.at | 21 ++
 tests/test-ovn.c |  2 +-
 8 files changed, 87 insertions(+), 35 deletions(-)

-- 
2.7.4

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

Re: [ovs-dev] [PATCH V2] datapath: Fix for force/commit action failures

[Greg Rose]

On 07/18/2017 04:29 PM, Joe Stringer wrote:

On 18 July 2017 at 08:42, Greg Rose  wrote:
> Upstream commit:
>  commit 8b97ac5bda17cfaa257bcab6180af0f43a2e87e0
>  Author: Greg Rose 
>  Date:   Fri Jul 14 12:42:49 2017 -0700
>
>  openvswitch: Fix for force/commit action failures
>
>  When there is an established connection in direction A->B, it is
>  possible to receive a packet on port B which then executes
>  ct(commit,force) without first performing ct() - ie, a lookup.
>  In this case, we would expect that this packet can delete the
>  existing entry so that we can commit a connection with direction B->A.
>  However, currently we only perform a check in skb_nfct_cached() for
>  whether OVS_CS_F_TRACKED is set and OVS_CS_F_INVALID is not set, ie
>  that a lookup previously occurred. In the above scenario, a lookup
>  has not occurred but we should still be able to statelessly look
>  up the existing entry and potentially delete the entry if it is
>  in the opposite direction.
>
>  This patch extends the check to also hint that if the action has the
>  force flag set, then we will lookup the existing entry so that the
>  force check at the end of skb_nfct_cached has the ability to delete
>  the connection.
>
>  Fixes: dd41d330b03 ("openvswitch: Add force commit.")
>  CC: Pravin Shelar 
>  CC: d...@openvswitch.org
>  Signed-off-by: Joe Stringer 
>  Signed-off-by: Greg Rose 
>  Signed-off-by: David S. Miller 
>
> Co-authored-by: Joe Stringer 
> Signed-off-by: Joe Stringer 
> Signed-off-by: Greg Rose 

Thanks for the backport, if you don't mind I'd like to hold off until
we can assemble the full series to sync with upstream, so we get the
commits in the same order. I believe you're working on that at the
moment, so I'll keep an eye out for when that series is available.

Cheers,
Joe


Sure, sounds good.

Thanks!

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

[ovs-dev] [PATCH v4 3/3] tunneling: Avoid datapath-recirc by combining recirc actions at xlate.

[Sugesh Chandran]

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

The following test results shows the performance improvement offered by
this optimization for tunnel encap.

  +-+
  dpdk0 | |
 -->obr-in|
| o--> gre0
+-+

   --> LOCAL
+---o-+
| | dpdk1
|br-p1o-->
| |
+-+

Test result on OVS master with DPDK 16.11.2 (Without optimization):

 # dpdk0

 RX packets : 7037641.60  / sec
 RX packet errors   : 0  / sec
 RX packets dropped : 7730632.90  / sec
 RX rate: 402.69 MB/sec

 # dpdk1

 TX packets : 7037641.60  / sec
 TX packet errors   : 0  / sec
 TX packets dropped : 0  / sec
 TX rate: 657.73 MB/sec
 TX processing cost per TX packets in nsec : 142.09

Test result on OVS master + DPDK 16.11.2 (With optimization):

 # dpdk0

 RX packets : 9386809.60  / sec
 RX packet errors   : 0  / sec
 RX packets dropped : 5381496.40  / sec
 RX rate: 537.11 MB/sec

 # dpdk1

 TX packets : 9386809.60  / sec
 TX packet errors   : 0  / sec
 TX packets dropped : 0  / sec
 TX rate: 877.29 MB/sec
 TX processing cost per TX packets in nsec : 106.53

The offered performance gain is approx 30%.

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-cache.c  |  32 +++-
 ofproto/ofproto-dpif-xlate-cache.h  |  13 +-
 ofproto/ofproto-dpif-xlate.c| 237 +++-
 ofproto/ofproto-dpif.c  |   3 +-
 tests/packet-type-aware.at  |  27 ++--
 tests/system-userspace-packet-type-aware.at |  24 +--
 7 files changed, 293 insertions(+), 61 deletions(-)

diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 1dd0d63..8d909de 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -5048,24 +5048,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-cache.c 
b/ofproto/ofproto-dpif-xlate-cache.c
index 9161701..6947f2f 100644
--- a/ofproto/ofproto-dpif-xlate-cache.c
+++ b/ofproto/ofproto-dpif-xlate-cache.c
@@ -89,7 +89,7 @@ xlate_cache_netdev(struct xc_entry *entry, const struct 
dpif_flow_stats *stats)
 /* Push stats and perform side effects of flow translation. */
 void
 xlate_push_stats_entry(struct xc_entry *entry,
-   const struct dpif_flow_stats *stats)
+   struct dpif_flow_stats *stats)
 {
 struct eth_addr dmac;
 
@@ -160,6 +160,14 @@ xlate_push_stats_entry(struct xc_entry *entry,
 entry->controller.am = NULL; /* One time only. */
 }
 break;
+case XC_TUNNEL_HEADER:
+if (entry->tunnel_hdr.operation == ADD) {
+stats->n_bytes += stats->n_packets * entry->tunnel_hdr.hdr_size;
+} else {
+stats->n_bytes -= stats->n_packets * entry->tunnel_hdr.hdr_size;
+}
+
+break;
 default:
 OVS_NOT_REACHED();
 }
@@ -167,7 +175,7 @@ xlate_push_stats_entry(struct xc_entry *entry,
 
 void
 xlate_push_stats(struct xlate_cache *xcache,
- const struct dpif_flow_stats *stats)
+ struct dpif_flow_stats *stats)
 {
 if (!stats->n_packets) {
 return;
@@ -245,6 +253,8 @@ xlate_cache_clear_entry(struct xc_entry *entry)
 entry->controller.am = NULL;
 }
 break;
+case XC_TUNNEL_HEADER:
+break;
 default:
 OVS_NOT_REACHED();
 }
@@ -279,3 +289,21 @@ xlate_cache_delete(struct xlate_cache *xcache)
 xlate_cache_uninit(xcache);
 free(xcache);
 }
+
+/* Append all the entries in src into dst and remove them from src.
+ * The caller must own both xc-caches to 

[ovs-dev] [PATCH v4 0/3] tunneling : Improving tunneling performance by avoiding dp recirc.

[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 also extended with 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.

Signed-off-by: Sugesh Chandran 
Signed-off-by: Zoltán Balogh 
Co-authored-by: Zoltán Balogh 

v4
 - Rebased on latest master.
 - Coding style fixes
 - Provide comment for tunnel-push without post actions.
 - Corrected new packet-aware test suites to pass userspace testsuites.
 - Changes on cache_steal function to use memcpy and ofpbuf_put_uninit
   functions.

v3
 - Rebased on latest master
 - Changed the xlate_cache copy function to avoid expensive ref update 
operations.
 - Updated the new packet-aware test cases to handle the non-recirc tunnel case.
 - Updated the commit message with performance results.

v2
 - Rebased on latest master.
 - Updated newely added packet-aware test case to honor tunnel  combine actions.
 - Folded related patches into single patch based on Joe's comments.
 - Do the translation only once for tunnel combine instead of two.


Sugesh Chandran (3):
  xlate: Clear tunnel mask along with other fields while combine
actions.
  tunneling: Calculate and update packet l4_offset in tunnel push.
  tunneling: Avoid datapath-recirc by combining recirc actions at xlate.

 lib/dpif-netdev.c   |  18 +--
 lib/netdev-native-tnl.c |   2 +
 ofproto/ofproto-dpif-xlate-cache.c  |  32 +++-
 ofproto/ofproto-dpif-xlate-cache.h  |  13 +-
 ofproto/ofproto-dpif-xlate.c| 238 +++-
 ofproto/ofproto-dpif.c  |   3 +-
 tests/packet-type-aware.at  |  27 ++--
 tests/system-userspace-packet-type-aware.at |  24 +--
 8 files changed, 296 insertions(+), 61 deletions(-)

-- 
2.7.4

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

[ovs-dev] [PATCH v4 1/3] xlate: Clear tunnel mask along with other fields while combine actions.

[Sugesh Chandran]

The tunnel mask in the translation state should be cleared along with other
context fields. It is necessary in 'apply_nested_clone_actions' as it will be
used to combine post tunnel output actions with tunnel push. This will assure
right openflow state while executing the translation.

Signed-off-by: Sugesh Chandran 
Signed-off-by: Zoltán Balogh 
Co-authored-by: Zoltán Balogh 
Acked-by: Joe Stringer 
---
 ofproto/ofproto-dpif-xlate.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 9d81ee3..b9fd886 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -3296,6 +3296,7 @@ apply_nested_clone_actions(struct xlate_ctx *ctx, const 
struct xport *in_dev,
 flow->in_port.ofp_port = out_dev->ofp_port;
 flow->metadata = htonll(0);
 memset(>tunnel, 0, sizeof flow->tunnel);
+memset(>wc->masks.tunnel, 0, sizeof ctx->wc->masks.tunnel);
 flow->tunnel.metadata.tab =
ofproto_get_tun_tab(_dev->xbridge->ofproto->up);
 ctx->wc->masks.tunnel.metadata.tab = flow->tunnel.metadata.tab;
-- 
2.7.4

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

[ovs-dev] [PATCH v4 2/3] tunneling: Calculate and update packet l4_offset in tunnel push.

[Sugesh Chandran]

The following tunnel combine patch series avoids the packets recirculation
after the tunnel push. So it is necessary to populate all relevant packet meta
data fields for the following combined action-set.

Consider a chained tunnel test case shown below,

PKT-IN --> TUNNEL_PUSH --> MOD_PKT_HDR --> TUNNEL_POP

In this eg: the last tunnel_pop operation uses the l4_offset in the packet to
validate the packets. So it must be calculated and updated in the packet before
executing the action. Since there is no recirculation now on, this calculation
is doing as part of tunnel_push.

Signed-off-by: Sugesh Chandran 
Signed-off-by: Zoltán Balogh 
Co-authored-by: Zoltán Balogh 
---
 lib/netdev-native-tnl.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/netdev-native-tnl.c b/lib/netdev-native-tnl.c
index 7f3cf98..5dbf583 100644
--- a/lib/netdev-native-tnl.c
+++ b/lib/netdev-native-tnl.c
@@ -163,12 +163,14 @@ netdev_tnl_push_ip_header(struct dp_packet *packet,
 ip6 = netdev_tnl_ipv6_hdr(eth);
 *ip_tot_size -= IPV6_HEADER_LEN;
 ip6->ip6_plen = htons(*ip_tot_size);
+packet->l4_ofs = dp_packet_size(packet) - *ip_tot_size;
 return ip6 + 1;
 } else {
 ip = netdev_tnl_ip_hdr(eth);
 ip->ip_tot_len = htons(*ip_tot_size);
 ip->ip_csum = recalc_csum16(ip->ip_csum, 0, ip->ip_tot_len);
 *ip_tot_size -= IP_HEADER_LEN;
+packet->l4_ofs = dp_packet_size(packet) - *ip_tot_size;
 return ip + 1;
 }
 }
-- 
2.7.4

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

Re: [ovs-dev] [PATCH v2] netdev: check for NULL fields in netdev_get_addrs

[Timothy M. Redaelli]

On 07/18/2017 05:25 PM, Daniel Alvarez Sanchez wrote:
> When the interfaces list is retrieved through getiffaddrs(), there
> might be elements with iface_name set to NULL.
> 
> This patch checks ifa_name to be not NULL before comparing it to the
> actual device name in the loop that calculates how many interfaces
> exist with that same name.
> 
> Also, this patch checks that ifa_netmask is not NULL for coherence
> with the existing code so that it doesn't allocate more memory
> than needed if this field is NULL.
> 
> Note, that these checks are already being done later in the function
> so it should be done in both places.
> 
> Signed-off-by: Daniel Alvarez 
> ---

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

Re: [ovs-dev] [PATCH] rhel: Fix creation of symlink for ocf script

[Aaron Conole]

Timothy Redaelli  writes:

> The policy is to use %files to track installed files.
>
> If %files is not used the resulting file is not owned by any package.
>
> Before this commit:
>  # rpm -qf /usr/lib/ocf/resource.d/ovn/ovndb-servers
>  file /usr/lib/ocf/resource.d/ovn/ovndb-servers is not owned by any package
>
> After this commit:
>  # rpm -qf /usr/lib/ocf/resource.d/ovn/ovndb-servers
>  openvswitch-ovn-common-2.7.90-1.fc26.x86_64
>
> Fixes: a4245b7869c8 ("ovn: Add ovn db servers ocf script in fedora packager")
>
> Signed-off-by: Timothy Redaelli 
> ---

LGTM

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

[ovs-dev] Roasted Duck Le Gang

[Bonesca Import & Export BV]

    [ View in browser ]( http://r.newsletter.bonescamail.nl/nru6rknyoatrf.html 
)   
 
[  ]( http://r.newsletter.bonescamail.nl/click/2n3cr2anhaoatrd.html ) 
 
Offer Roasted Boneless Duck
 
Gegarte Ente Ohne Knochen/Geroosterde Eend Zonder Bot/Canard Cuit Desosse
 
10 kilo box size 16 (550-600g) & 18 (600-650g)
 
1 box € 7,45
10 box € 7,15
1 palet (80 box) € 6,95
3 palets € 6,85
5 palets € 6,75
Truckload (1840 boxes): € 6,65 per kilo!!!    






   [ For more offers click here ]( 
http://r.newsletter.bonescamail.nl/click/2n3cr2ao9qoatrd.html )     
This email was sent to d...@openvswitch.org
You received this email because you are registered with Bonesca Import en 
Export BV
 
[ Unsubscribe here ]( http://r.newsletter.bonescamail.nl/nru6rknyoatrg.html )  

Sent by
[  ]( http://r.newsletter.bonescamail.nl/click/2n3cr2ap26oatrd.html )     
© 2017 Bonesca Import en Export BV  

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

[ovs-dev] [PATCH v1 1/1] ovn: l3ha fix unexpected ARP requests on pcap during tests

[Miguel Angel Ajo]

For testing l3ha datapath we have an external port on a separate sim
instance (ext1), and we send an UDP packet that we expect to see
going through the specific MASTER gateway (gw1 or gw2) and reaching
the final ext1-vif port on ext1.

ovn_arp_populate macro din't know about the BRIDGE/IP/MAC of ext1-vif
port, and didn't populate the tables, so in some cases an ARP
request was sent from alice external distributed port to the external
network, which wasn't expected on the OVN_CHECK_PACKETS macro.

This patch adds a macro to let us register extra arp entries before
running the tests, also makes sure that ovn-controller has synchronized
and waits one more second to make sure that BFD sessions are fully
established between gateways.

Signed-off-by: Miguel Angel Ajo 
---
 tests/ofproto-macros.at | 11 ++-
 tests/ovn.at| 17 -
 2 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/tests/ofproto-macros.at b/tests/ofproto-macros.at
index 23b0321..afba585 100644
--- a/tests/ofproto-macros.at
+++ b/tests/ofproto-macros.at
@@ -235,6 +235,15 @@ net_attach () {
 || return 1
 }
 
+# ovn_register_arp BRIDGE IP MAC
+#
+# Registers bridge/ip/mac triplet to the arp_table list which can be
+# populated via the ovn_populate_arp function.
+ovn_register_arp() {
+local sandbox=$1 bridge=$2 ip=$3 mac=$4
+arp_table="$arp_table $sandbox,$bridge,$ip,$mac"
+}  
+
 # ovn_attach NETWORK BRIDGE IP [MASKLEN]
 #
 # First, this command attaches BRIDGE to interconnection network NETWORK, just
@@ -247,7 +256,7 @@ ovn_attach() {
 net_attach $net $bridge || return 1
 
 mac=`ovs-vsctl get Interface $bridge mac_in_use | sed s/\"//g`
-arp_table="$arp_table $sandbox,$bridge,$ip,$mac"
+ovn_register_arp $sandbox $bridge $ip $mac
 ovs-appctl netdev-dummy/ip4addr $bridge $ip/$masklen >/dev/null || return 1
 ovs-appctl ovs/route/add $ip/$masklen $bridge >/dev/null || return 1
 ovs-vsctl \
diff --git a/tests/ovn.at b/tests/ovn.at
index 248aea4..22d3ab1 100644
--- a/tests/ovn.at
+++ b/tests/ovn.at
@@ -6851,7 +6851,6 @@ ovs-vsctl -- add-port br-int ext1-vif1 -- \
 # Pre-populate the hypervisors' ARP tables so that we don't lose any
 # packets for ARP resolution (native tunneling doesn't queue packets
 # for ARP resolution).
-ovn_populate_arp
 
 ovn-nbctl create Logical_Router name=R1
 
@@ -6907,11 +6906,19 @@ as gw1 ovs-vsctl set open . 
external-ids:ovn-bridge-mappings=phys:br-phys
 as gw2 ovs-vsctl set open . external-ids:ovn-bridge-mappings=phys:br-phys
 as ext1 ovs-vsctl set open . external-ids:ovn-bridge-mappings=phys:br-phys
 
-AT_CHECK([ovn-nbctl --timeout=3 --wait=sb sync], [0], [ignore])
+AT_CHECK([ovn-nbctl --timeout=3 --wait=hv sync], [0], [ignore])
 
-# Allow some time for ovn-northd and ovn-controller to catch up.
-# XXX This should be more systematic.
-sleep 2
+ovn_register_arp ext1 br-phys 172.16.1.3 f0:00:00:01:02:04
+
+ovn_populate_arp
+
+for x in hv1 gw1 gw2 ext1; do
+   echo tnl/arp/show at ${x}:
+   as $x ovs-appctl tnl/arp/show
+done
+
+# allow BFD sessions to be established and up/steady
+sleep 3
 
 ip_to_hex() {
 printf "%02x%02x%02x%02x" "$@"
-- 
1.8.3.1

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

Re: [ovs-dev] [PATCH 2/2] dpif-netdev: Indicate support for various ct features.

[Darrell Ball]

This change does not seem to be all that useful.

When rules are constructed, mask and action support do check previously probed 
support
which will be ‘TRUE’.

Another way to see that the below settings are not useful is to set everything 
to ‘false’ (see below) and run all
the system tests in userspace, which will all pass.

By the way, the .max_vlan_headers and .max_mpls_headers fields, which I did not 
change are pretty big
numbers and I am fairly sure OVS does not really support that many vlans and 
labels.

static struct odp_support dp_netdev_support = {
.max_vlan_headers = SIZE_MAX,
.max_mpls_depth = SIZE_MAX,
.recirc = false,
.ct_state = false,
.ct_zone = false,
.ct_mark = false,
.ct_label = false,
.ct_state_nat = false,
.ct_orig_tuple = false,
.ct_orig_tuple6 = false,
};

I think it may be better to clean this up. I can do this if you are ok with 
that; either way is fine with me.

Thanks Darrell



On 7/18/17, 11:18 PM, "ovs-dev-boun...@openvswitch.org on behalf of Justin 
Pettit"  wrote:

The userspace datapath hardcodes support for the features it supports,
but it was missing "ct_state_nat", "ct_orig_tuple", and "ct_orig_tuple6".

Signed-off-by: Justin Pettit 
---
 lib/dpif-netdev.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 1dd0d63ebddb..3cd0e95eb0a3 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -112,6 +112,9 @@ static struct odp_support dp_netdev_support = {
 .ct_zone = true,
 .ct_mark = true,
 .ct_label = true,
+.ct_state_nat = true,
+.ct_orig_tuple = true,
+.ct_orig_tuple6 = true,
 };
 
 /* Stores a miniflow with inline values */
-- 
2.7.4

___
dev mailing list
d...@openvswitch.org

https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=IB5v8vX446JEBsGI6fRh-BZgavpw4tCmjNae3I_Ow8I=teWT8FxDJPD0Q3Zc0MbSAz0S4zGTZiN01Zpio7eJzKk=
 


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

[ovs-dev] [PATCH v3] Update relevant artifacts to add support for DPDK 17.05.1.

[Michal Weglicki]

Upgrading to DPDK 17.05.1 stable release adds new
significant features relevant to OVS, including,
but not limited to:
- tun/tap PMD,
- VFIO hotplug support,
- Generic flow API.

Following changes are applied:
- netdev-dpdk: Changes required by DPDK API modifications.
- doc: Because of DPDK API changes, backward compatibility
  with previous DPDK releases will be broken, thus all
  relevant documentation entries are updated.
- .travis: DPDK version change from 16.11.1 to 17.05.1.
- rhel/openvswitch-fedora.spec.in: DPDK version change
  from 16.11 to 17.05.1

v1->v2: Patch rebase.
v2->v3: Fixed wrong formating after v2 patch rebase.

Signed-off-by: Michal Weglicki 
Reviewed-by: Aaron Conole 
---
 .travis/linux-build.sh   |   2 +-
 Documentation/intro/install/dpdk.rst |   8 +-
 Documentation/topics/dpdk/vhost-user.rst |   8 +-
 NEWS |   1 +
 lib/netdev-dpdk.c| 144 +++
 rhel/openvswitch-fedora.spec.in  |   2 +-
 tests/dpdk/ring_client.c |   6 +-
 7 files changed, 105 insertions(+), 66 deletions(-)

diff --git a/.travis/linux-build.sh b/.travis/linux-build.sh
index f66b534..efccdf1 100755
--- a/.travis/linux-build.sh
+++ b/.travis/linux-build.sh
@@ -80,7 +80,7 @@ fi
 
 if [ "$DPDK" ]; then
 if [ -z "$DPDK_VER" ]; then
-DPDK_VER="16.11.2"
+DPDK_VER="17.05.1"
 fi
 install_dpdk $DPDK_VER
 if [ "$CC" = "clang" ]; then
diff --git a/Documentation/intro/install/dpdk.rst 
b/Documentation/intro/install/dpdk.rst
index a05aa1a..4a178f3 100644
--- a/Documentation/intro/install/dpdk.rst
+++ b/Documentation/intro/install/dpdk.rst
@@ -40,7 +40,7 @@ Build requirements
 In addition to the requirements described in :doc:`general`, building Open
 vSwitch with DPDK will require the following:
 
-- DPDK 16.11
+- DPDK 17.05.1
 
 - A `DPDK supported NIC`_
 
@@ -69,9 +69,9 @@ Install DPDK
 #. Download the `DPDK sources`_, extract the file and set ``DPDK_DIR``::
 
$ cd /usr/src/
-   $ wget http://fast.dpdk.org/rel/dpdk-16.11.2.tar.xz
-   $ tar xf dpdk-16.11.2.tar.xz
-   $ export DPDK_DIR=/usr/src/dpdk-stable-16.11.2
+   $ wget http://fast.dpdk.org/rel/dpdk-17.05.1.tar.xz
+   $ tar xf dpdk-17.05.1.tar.xz
+   $ export DPDK_DIR=/usr/src/dpdk-stable-17.05.1
$ cd $DPDK_DIR
 
 #. (Optional) Configure DPDK as a shared library
diff --git a/Documentation/topics/dpdk/vhost-user.rst 
b/Documentation/topics/dpdk/vhost-user.rst
index e76da5f..9f11ea1 100644
--- a/Documentation/topics/dpdk/vhost-user.rst
+++ b/Documentation/topics/dpdk/vhost-user.rst
@@ -292,9 +292,9 @@ To begin, instantiate a guest as described in 
:ref:`dpdk-vhost-user` or
 DPDK sources to VM and build DPDK::
 
 $ cd /root/dpdk/
-$ wget http://fast.dpdk.org/rel/dpdk-16.11.2.tar.xz
-$ tar xf dpdk-16.11.2.tar.xz
-$ export DPDK_DIR=/root/dpdk/dpdk-stable-16.11.2
+$ wget http://fast.dpdk.org/rel/dpdk-17.05.1.tar.xz
+$ tar xf dpdk-17.05.1.tar.xz
+$ export DPDK_DIR=/root/dpdk/dpdk-stable-17.05.1
 $ export DPDK_TARGET=x86_64-native-linuxapp-gcc
 $ export DPDK_BUILD=$DPDK_DIR/$DPDK_TARGET
 $ cd $DPDK_DIR
@@ -378,7 +378,7 @@ Sample XML
 
 
   
-  
+  
   
   
 
diff --git a/NEWS b/NEWS
index d61fc5f..3f58e8b 100644
--- a/NEWS
+++ b/NEWS
@@ -21,6 +21,7 @@ Post-v2.7.0
still can be configured via extra arguments for DPDK EAL.
  * dpdkvhostuser ports are marked as deprecated.  They will be removed
in an upcoming release.
+ * Support for DPDK v17.05.1.
- IPFIX now provides additional counters:
  * Total counters since metering process startup.
  * Per-flow TCP flag counters.
diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index ea17b97..5e767e1 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -22,6 +22,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #include 
 #include 
@@ -31,7 +34,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "dirs.h"
 #include "dp-packet.h"
@@ -56,6 +59,8 @@
 #include "timeval.h"
 #include "unixctl.h"
 
+enum {VIRTIO_RXQ, VIRTIO_TXQ, VIRTIO_QNUM};
+
 VLOG_DEFINE_THIS_MODULE(netdev_dpdk);
 static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 20);
 
@@ -171,6 +176,21 @@ static const struct rte_eth_conf port_conf = {
 },
 };
 
+/*
+ * These callbacks allow virtio-net devices to be added to vhost ports when
+ * configuration has been fully completed.
+ */
+static int new_device(int vid);
+static void destroy_device(int vid);
+static int vring_state_changed(int vid, uint16_t queue_id, int enable);
+static const struct vhost_device_ops virtio_net_device_ops =
+{
+.new_device =  new_device,
+.destroy_device = destroy_device,
+.vring_state_changed = vring_state_changed,
+.features_changed = NULL
+};
+
 enum 

Re: [ovs-dev] BELANGRIJKE MEDEDELING

[Nissan, Caroline via dev]

BELANGRIJKE MEDEDELING

Je Q2-screening is gestart en ook je e-mailaccount was een paar uur geleden van 
het onbekende locatie IP-adres: 103.240.180.228, je moet op 
UPDATE klikken om je e-mailaccount te 
vernieuwen en te upgraden binnen 2HOURS om te voorkomen dat account verwijderd 
is Van de server.

ITS helpdesk
ADMIN TEAM
© Copyright 2017 Microsoft
Alle rechten voorbehouden
bedankt voor je medewerking.

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

Re: [ovs-dev] [PATCH v3 3/3] tunneling: Avoid datapath-recirc by combining recirc actions at xlate.

[Chandran, Sugesh]

Regards
_Sugesh


> -Original Message-
> From: Joe Stringer [mailto:j...@ovn.org]
> Sent: Wednesday, July 19, 2017 2:34 AM
> To: Chandran, Sugesh 
> Cc: ovs dev ; Andy Zhou ; Zoltán
> Balogh 
> Subject: Re: [PATCH v3 3/3] tunneling: Avoid datapath-recirc by combining
> recirc actions at xlate.
> 
> On 18 July 2017 at 17:40, Joe Stringer  wrote:
> > On 18 July 2017 at 10:49, Sugesh Chandran 
> wrote:
> >> +static bool
> >> +validate_and_combine_post_tnl_actions(struct xlate_ctx *ctx,
> >> +  const struct xport *xport,
> >> +  struct xport *out_dev,
> >> +  struct ovs_action_push_tnl
> >> +tnl_push_data) {
> > ...
> >> +if (ctx->odp_actions->size > push_action_size) {
> >> +/* Update the CLONE action only when combined. */
> >> +nl_msg_end_nested(ctx->odp_actions, clone_ofs);
> >> +} else {
> >> +/* No actions after the tunnel, no need of clone. */
> >> +nl_msg_cancel_nested(ctx->odp_actions, clone_ofs);
> >> +odp_put_tnl_push_action(ctx->odp_actions, _push_data);
> >
> > I looked at this line again for this version since I didn't understand
> > it last time around, and I'm still a bit confused. If there's no
> > actions to run on the second bridge, then the copy of the packet which
> > is tunneled is effectively dropped. If that copy of the packet is
> > dropped, then why do we need the tunnel action at all? If I follow
> > correctly, then this means that if you have two bridges, where the
> > first bridge has output(tunnel),output(other_device) then the second
> > bridge where the tunneling occurs has no flows, then the datapath flow
> > will end up as something like:
> >
> > push_tnl(...),output(other_device).
> >
> > I realise that the testsuite breaks if you remove this line, but maybe
> > the testsuite needs fixing for these cases?
> 
> On second thought, this should probably be a logically separate follow-up
> patch even if we agree to change it.
[Sugesh] That make sense. Perhaps we can add comment like
/*
  * XXX : Only needed for the unit test cases. Few tests in 'make check'
  * doesn’t have any actions to handle encaped packets.
  */

Is that OK?




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

Re: [ovs-dev] [PATCH] ovn-architecture: Add notes on L3 gateway HA.

[Miguel Angel Ajo Pelayo]

Sounds great, thank you!

Acked-by: Miguel Angel Ajo 

On Sun, Jul 16, 2017 at 10:09 PM, Russell Bryant  wrote:

> Add some comments to the ovn-architecture document that distributed
> gateway ports can also be made highly available.  Provide a brief
> overview of the approach and point to the gateway HA design document
> for a more detailed discussion of the approach taken.
>
> Signed-off-by: Russell Bryant 
> ---
>  ovn/ovn-architecture.7.xml | 22 ++
>  1 file changed, 22 insertions(+)
>
> diff --git a/ovn/ovn-architecture.7.xml b/ovn/ovn-architecture.7.xml
> index e91be8bf6..5f73e2067 100644
> --- a/ovn/ovn-architecture.7.xml
> +++ b/ovn/ovn-architecture.7.xml
> @@ -1341,6 +1341,28 @@
>  logical patch port representing the distributed gateway port.
>
>
> +  High Availability for Distributed Gateway Ports
> +
> +  
> +OVN allows you to specify a prioritized list of chassis for a
> distributed
> +gateway port.  This is done by associating multiple
> +Gateway_Chassis rows with a Logical_Router_Port code>
> +in the OVN_Northbound database.
> +  
> +
> +  
> +When multiple chassis have been specified for a gateway, all chassis
> that
> +may send packets to that gateway will enable BFD on tunnels to all
> +configured gateway chassis.  The current master chassis for the
> gateway
> +is the highest priority gateway chassis that is currently viewed as
> +active based on BFD status.
> +  
> +
> +  
> +For more information on L3 gateway high availability, please refer to
> +http://docs.openvswitch.org/en/latest/topics/high-availability.
> +  
> +
>Life Cycle of a VTEP gateway
>
>
> --
> 2.13.3
>
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] UPS issue #009708161: unable to delivery parcel

[www-data]

Dear Customer,

This is to confirm that your item has been shipped at July 18.

Review the document that is attached to this e-mail!

Kind regards,
 ,
UPS Senior Station Manager.

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

Re: [ovs-dev] [PATCH 1/2] Set release date for 2.7.2.

[Justin Pettit]

> On Jul 18, 2017, at 9:43 PM, Numan Siddique  wrote:
> 
> 
> 
> On Wed, Jul 19, 2017 at 5:37 AM, Justin Pettit  wrote:
> 
> > On Jul 18, 2017, at 4:44 PM, Joe Stringer  wrote:
> >
> > On 18 July 2017 at 16:29, Justin Pettit  wrote:
> >> Signed-off-by: Justin Pettit 
> >
> > Acked-by: Joe Stringer 
> 
> Thanks.  I pushed these to branch-2.7.
> 
> 
> Hi Justin, can you please also create a tag for v2.7.2.

It's a bad oversight, but Ben's the only one that can sign tags.  We need to 
address that.

In the meantime, Ben, can you do that when you get a chance?

--Justin


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

[ovs-dev] [PATCH 1/2] odp-util: Document size of OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV4.

[Justin Pettit]

This attribute shares space with OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV6, but
it's still worth documenting.

Signed-off-by: Justin Pettit 
---
 lib/odp-util.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/odp-util.h b/lib/odp-util.h
index f49aaa8160d9..9d4e224a747e 100644
--- a/lib/odp-util.h
+++ b/lib/odp-util.h
@@ -131,6 +131,7 @@ void odp_portno_name_format(const struct hmap *portno_names,
  *  OVS_KEY_ATTR_CT_MARK 4-- 4  8
  *  OVS_KEY_ATTR_CT_LABEL   16-- 4 20
  *  OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV6 40-- 4 44
+ *  OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV4  --- -  - (shared  with 
_CT_ORIG_TUPLE_IPV6)
  *  OVS_KEY_ATTR_ETHERNET   12-- 4 16
  *  OVS_KEY_ATTR_ETHERTYPE   2 2 4  8  (outer VLAN 
ethertype)
  *  OVS_KEY_ATTR_VLAN2 2 4  8
-- 
2.7.4

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

[ovs-dev] [PATCH 2/2] dpif-netdev: Indicate support for various ct features.

[Justin Pettit]

The userspace datapath hardcodes support for the features it supports,
but it was missing "ct_state_nat", "ct_orig_tuple", and "ct_orig_tuple6".

Signed-off-by: Justin Pettit 
---
 lib/dpif-netdev.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 1dd0d63ebddb..3cd0e95eb0a3 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -112,6 +112,9 @@ static struct odp_support dp_netdev_support = {
 .ct_zone = true,
 .ct_mark = true,
 .ct_label = true,
+.ct_state_nat = true,
+.ct_orig_tuple = true,
+.ct_orig_tuple6 = true,
 };
 
 /* Stores a miniflow with inline values */
-- 
2.7.4

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