Re: [ovs-dev] [PATCH V6 00/13] Netdev vxlan-decap offload

[Ilya Maximets]

On 6/23/21 5:48 PM, Eli Britstein wrote:
 @@ -1009,7 +1009,7 @@ parse_vxlan_match(struct flow_patterns *patterns,
   return 0;
   }

 -static int
 +static int OVS_UNUSED
> 
> Note that if experimental is allowed, the OVS_UNUSED attribute is misleading.

Yeah, I know.  We might introduce OVS_MAY_BE_UNUSED macro someday, but that is
really minor.

> 
> Also see below.
> 
   parse_flow_tnl_match(struct netdev *tnldev,
    struct flow_patterns *patterns,
    odp_port_t orig_in_port,
 @@ -1031,7 +1031,7 @@ parse_flow_tnl_match(struct netdev *tnldev,

   static int
   parse_flow_match(struct netdev *netdev,
 - odp_port_t orig_in_port,
 + odp_port_t orig_in_port OVS_UNUSED,
    struct flow_patterns *patterns,
    struct match *match)
   {
 @@ -1045,10 +1045,12 @@ parse_flow_match(struct netdev *netdev,
   }

   patterns->physdev = netdev;
 +#ifdef ALLOW_EXPERIMENTAL_API /* Packet restoration API required. */
> 
> In my opinion those should be removed in netdev-offload-dpdk.c, and keep such 
> #ifdef only in netdev-dpdk (with stubs), so later, when dpdk removes the 
> experimental attribute, there will be a single place to change.
> 
> This applies both to parse_flow_tnl_match and add_tnl_pop_action.
> 
> However, this is not critical and I would not hold the merge because of this.

I agree that it's a bit of an overthinking from my side, but we will
need to introduce this kind of guarding here if DPDK APIs will become
non-experimental not all at once.  I'm not sure if that is a possible
scenario, but just in case.  Looking more at the code, I agree that
they are unnecessary for current version, but let them be, as they will
remind us to re-check things once some of APIs will become stable.

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

Re: [ovs-dev] [PATCH V6 00/13] Netdev vxlan-decap offload

[Eli Britstein]

On 6/23/2021 6:18 PM, Ferriter, Cian wrote:

External email: Use caution opening links or attachments



-Original Message-
From: dev  On Behalf Of Ferriter, Cian
Sent: Wednesday 23 June 2021 13:38
To: Ilya Maximets ; Eli Britstein ; 
d...@openvswitch.org
Cc: ivan.ma...@oktetlabs.ru; Ameer Mahagneh ; Majd Dibbiny 

Subject: Re: [ovs-dev] [PATCH V6 00/13] Netdev vxlan-decap offload

Hi all,

As part of rebasing our AVX512 DPIF on this patchset, I tested this patchset 
with partial HWOL and I'm
seeing strange behaviour.

I'll report back more detailed findings soon, just wanted to mention this here 
as soon as I found the
issue.

Thanks,
Cian


More details on the issue I'm seeing:
I'm using Ilya's branch from Github:
https://github.com/igsilya/ovs/tree/tmp-vxlan-decap

~/ovs_scripts# $OVS_DIR/utilities/ovs-vsctl list Open_vSwitch
dpdk_version: "DPDK 20.11.1"
other_config: {dpdk-hugepage-dir="/mnt/huge", dpdk-init="true", dpdk-lcore-mask="0x1", 
dpdk-socket-mem="2048,0", emc-insert-inv-prob="0", hw-offload="true", pmd-cpu-mask="0x2"}

~/ovs_scripts# $OVS_DIR/utilities/ovs-vsctl show
31584ce5-09c1-44b3-ab27-1a0308d63fff
 Bridge br0
 datapath_type: netdev
 Port br0
 Interface br0
 type: internal
 Port phy0
 Interface phy0
 type: dpdk
 options: {dpdk-devargs="5e:00.0"}

~/ovs_scripts# $OVS_DIR/utilities/ovs-ofctl dump-flows br0
  cookie=0x0, duration=29.466s, table=0, n_packets=0, n_bytes=0, in_port=phy0 
actions=IN_PORT

I'm expecting the flow to be partially offloaded, but I get a segfault when 
using the above branch. More info on the segfault below:

Thread 13 "pmd-c01/id:8" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f9f72734700 (LWP 19327)]
0x56163bf0d825 in set_error (error=0x0, type=RTE_FLOW_ERROR_TYPE_ATTR) at 
lib/netdev-dpdk.h:84
(gdb) bt
#0  0x56163bf0d825 in set_error (error=0x0, type=RTE_FLOW_ERROR_TYPE_ATTR) 
at lib/netdev-dpdk.h:84
Yes, it is caused by passing NULL instead of valid struct rte_error, by 
Ilya's comments. I will fix it in v7.

#1  0x56163bf0d8d3 in netdev_dpdk_rte_flow_get_restore_info 
(netdev=0x1bfc65c80, p=0x19033af00, info=0x7f9f72729a20, error=0x0) at 
lib/netdev-dpdk.h:119
#2  0x56163bf14da3 in netdev_offload_dpdk_hw_miss_packet_recover 
(netdev=0x1bfc65c80, packet=0x19033af00) at lib/netdev-offload-dpdk.c:2133
#3  0x56163bde3662 in netdev_hw_miss_packet_recover (netdev=0x1bfc65c80, 
packet=0x19033af00) at lib/netdev-offload.c:265
#4  0x56163bda19a9 in dp_netdev_hw_flow (pmd=0x7f9f72735010, port_no=2, 
packet=0x19033af00, flow=0x7f9f72729b98) at lib/dpif-netdev.c:7087
#5  0x56163bda1c5c in dfc_processing (pmd=0x7f9f72735010, packets_=0x7f9f727310d0, 
keys=0x7f9f7272c480, missed_keys=0x7f9f7272c370, batches=0x7f9f72729f60, 
n_batches=0x7f9f72730f70, flow_map=0x7f9f72729c50, n_flows=0x7f9f72730f78, 
index_map=0x7f9f72729c30 "", md_is_valid=false, port_no=2) at 
lib/dpif-netdev.c:7168
#6  0x56163bda2f3e in dp_netdev_input__ (pmd=0x7f9f72735010, 
packets=0x7f9f727310d0, md_is_valid=false, port_no=2) at lib/dpif-netdev.c:7475
#7  0x56163bda3105 in dp_netdev_input (pmd=0x7f9f72735010, 
packets=0x7f9f727310d0, port_no=2) at lib/dpif-netdev.c:7519
#8  0x56163bd9ab04 in dp_netdev_process_rxq_port (pmd=0x7f9f72735010, 
rxq=0x56163fb3f610, port_no=2) at lib/dpif-netdev.c:4774
#9  0x56163bd9ee17 in pmd_thread_main (f_=0x7f9f72735010) at 
lib/dpif-netdev.c:6063
#10 0x56163be71c88 in ovsthread_wrapper (aux_=0x56163fb3fe70) at 
lib/ovs-thread.c:383
#11 0x7f9f884cf6db in start_thread (arg=0x7f9f72734700) at 
pthread_create.c:463
#12 0x7f9f862bb71f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

In netdev_offload_dpdk_hw_miss_packet_recover() calls 
netdev_dpdk_rte_flow_get_restore_info() with a NULL for the struct 
rte_flow_error *error argument:

 if (netdev_dpdk_rte_flow_get_restore_info(netdev, packet,
   _restore_info, NULL)) {
 /* This function is called for every packet, and in most cases there
  * will be no restore info from the HW, thus error is expected.
  */
 return 0;
 }

There are 2 "netdev_dpdk_rte_flow_get_restore_info()" functions. One in 
lib/netdev-dpdk.h and one in lib/netdev-dpdk.c.

I don't have the experimental API enabled, so I'm using the function rom 
lib/netdev-dpdk.h.


-Original Message-
From: dev  On Behalf Of Ilya Maximets
Sent: Tuesday 22 June 2021 16:55
To: Eli Britstein ; d...@openvswitch.org; Ilya Maximets 

Cc: ivan.ma...@oktetlabs.ru; Ameer Mahagneh ; Majd Dibbiny 

Subject: Re: [ovs-dev] [PATCH V6 00/13] Netdev vxlan-decap offload

On 4/4/21 11:54 AM, Eli Britstein wrote:

VXLAN decap in OVS-DPDK configuration consists of two

Re: [ovs-dev] [PATCH V6 00/13] Netdev vxlan-decap offload

[Ferriter, Cian]

> -Original Message-
> From: Ilya Maximets 
> Sent: Wednesday 23 June 2021 16:25
> To: Ferriter, Cian ; Ilya Maximets 
> ; Eli Britstein
> ; d...@openvswitch.org
> Cc: ivan.ma...@oktetlabs.ru; Ameer Mahagneh ; Majd Dibbiny 
> 
> Subject: Re: [ovs-dev] [PATCH V6 00/13] Netdev vxlan-decap offload
> 
> On 6/23/21 5:18 PM, Ferriter, Cian wrote:
> >> -Original Message-
> >> From: dev  On Behalf Of Ferriter, Cian
> >> Sent: Wednesday 23 June 2021 13:38
> >> To: Ilya Maximets ; Eli Britstein ; 
> >> d...@openvswitch.org
> >> Cc: ivan.ma...@oktetlabs.ru; Ameer Mahagneh ; Majd 
> >> Dibbiny 
> >> Subject: Re: [ovs-dev] [PATCH V6 00/13] Netdev vxlan-decap offload
> >>
> >> Hi all,
> >>
> >> As part of rebasing our AVX512 DPIF on this patchset, I tested this 
> >> patchset with partial HWOL and
> I'm
> >> seeing strange behaviour.
> >>
> >> I'll report back more detailed findings soon, just wanted to mention this 
> >> here as soon as I found
> the
> >> issue.
> >>
> >> Thanks,
> >> Cian
> >>
> >
> > More details on the issue I'm seeing:
> > I'm using Ilya's branch from Github:
> > https://github.com/igsilya/ovs/tree/tmp-vxlan-decap
> >
> > ~/ovs_scripts# $OVS_DIR/utilities/ovs-vsctl list Open_vSwitch
> > dpdk_version: "DPDK 20.11.1"
> > other_config: {dpdk-hugepage-dir="/mnt/huge", dpdk-init="true", 
> > dpdk-lcore-mask="0x1", dpdk-
> socket-mem="2048,0", emc-insert-inv-prob="0", hw-offload="true", 
> pmd-cpu-mask="0x2"}
> >
> > ~/ovs_scripts# $OVS_DIR/utilities/ovs-vsctl show
> > 31584ce5-09c1-44b3-ab27-1a0308d63fff
> > Bridge br0
> > datapath_type: netdev
> > Port br0
> > Interface br0
> > type: internal
> > Port phy0
> > Interface phy0
> > type: dpdk
> > options: {dpdk-devargs="5e:00.0"}
> >
> > ~/ovs_scripts# $OVS_DIR/utilities/ovs-ofctl dump-flows br0
> >  cookie=0x0, duration=29.466s, table=0, n_packets=0, n_bytes=0, 
> > in_port=phy0 actions=IN_PORT
> >
> > I'm expecting the flow to be partially offloaded, but I get a segfault when 
> > using the above branch.
> More info on the segfault below:
> >
> > Thread 13 "pmd-c01/id:8" received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 0x7f9f72734700 (LWP 19327)]
> > 0x56163bf0d825 in set_error (error=0x0, type=RTE_FLOW_ERROR_TYPE_ATTR) 
> > at lib/netdev-dpdk.h:84
> > (gdb) bt
> > #0  0x56163bf0d825 in set_error (error=0x0, 
> > type=RTE_FLOW_ERROR_TYPE_ATTR) at lib/netdev-
> dpdk.h:84
> > #1  0x56163bf0d8d3 in netdev_dpdk_rte_flow_get_restore_info 
> > (netdev=0x1bfc65c80, p=0x19033af00,
> info=0x7f9f72729a20, error=0x0) at lib/netdev-dpdk.h:119
> > #2  0x56163bf14da3 in netdev_offload_dpdk_hw_miss_packet_recover 
> > (netdev=0x1bfc65c80,
> packet=0x19033af00) at lib/netdev-offload-dpdk.c:2133
> > #3  0x56163bde3662 in netdev_hw_miss_packet_recover 
> > (netdev=0x1bfc65c80, packet=0x19033af00) at
> lib/netdev-offload.c:265
> > #4  0x56163bda19a9 in dp_netdev_hw_flow (pmd=0x7f9f72735010, port_no=2, 
> > packet=0x19033af00,
> flow=0x7f9f72729b98) at lib/dpif-netdev.c:7087
> > #5  0x56163bda1c5c in dfc_processing (pmd=0x7f9f72735010, 
> > packets_=0x7f9f727310d0,
> keys=0x7f9f7272c480, missed_keys=0x7f9f7272c370, batches=0x7f9f72729f60, 
> n_batches=0x7f9f72730f70,
> flow_map=0x7f9f72729c50, n_flows=0x7f9f72730f78, index_map=0x7f9f72729c30 "", 
> md_is_valid=false,
> port_no=2) at lib/dpif-netdev.c:7168
> > #6  0x56163bda2f3e in dp_netdev_input__ (pmd=0x7f9f72735010, 
> > packets=0x7f9f727310d0,
> md_is_valid=false, port_no=2) at lib/dpif-netdev.c:7475
> > #7  0x56163bda3105 in dp_netdev_input (pmd=0x7f9f72735010, 
> > packets=0x7f9f727310d0, port_no=2) at
> lib/dpif-netdev.c:7519
> > #8  0x56163bd9ab04 in dp_netdev_process_rxq_port (pmd=0x7f9f72735010, 
> > rxq=0x56163fb3f610,
> port_no=2) at lib/dpif-netdev.c:4774
> > #9  0x56163bd9ee17 in pmd_thread_main (f_=0x7f9f72735010) at 
> > lib/dpif-netdev.c:6063
> > #10 0x56163be71c88 in ovsthread_wrapper (aux_=0x56163fb3fe70) at 
> > lib/ovs-thread.c:383
> > #11 0x7f9f884cf6db in start_thread (arg=0x7f9f72734700) at 
> > pthread_create.c:463
> > #12 0x7f9f862bb71f in clone () at 
&

Re: [ovs-dev] [PATCH V6 00/13] Netdev vxlan-decap offload

[Ilya Maximets]

On 6/23/21 5:18 PM, Ferriter, Cian wrote:
>> -Original Message-
>> From: dev  On Behalf Of Ferriter, Cian
>> Sent: Wednesday 23 June 2021 13:38
>> To: Ilya Maximets ; Eli Britstein ; 
>> d...@openvswitch.org
>> Cc: ivan.ma...@oktetlabs.ru; Ameer Mahagneh ; Majd 
>> Dibbiny 
>> Subject: Re: [ovs-dev] [PATCH V6 00/13] Netdev vxlan-decap offload
>>
>> Hi all,
>>
>> As part of rebasing our AVX512 DPIF on this patchset, I tested this patchset 
>> with partial HWOL and I'm
>> seeing strange behaviour.
>>
>> I'll report back more detailed findings soon, just wanted to mention this 
>> here as soon as I found the
>> issue.
>>
>> Thanks,
>> Cian
>>
> 
> More details on the issue I'm seeing:
> I'm using Ilya's branch from Github:
> https://github.com/igsilya/ovs/tree/tmp-vxlan-decap
> 
> ~/ovs_scripts# $OVS_DIR/utilities/ovs-vsctl list Open_vSwitch
> dpdk_version: "DPDK 20.11.1"
> other_config: {dpdk-hugepage-dir="/mnt/huge", dpdk-init="true", 
> dpdk-lcore-mask="0x1", dpdk-socket-mem="2048,0", emc-insert-inv-prob="0", 
> hw-offload="true", pmd-cpu-mask="0x2"}
> 
> ~/ovs_scripts# $OVS_DIR/utilities/ovs-vsctl show
> 31584ce5-09c1-44b3-ab27-1a0308d63fff
> Bridge br0
> datapath_type: netdev
> Port br0
> Interface br0
> type: internal
> Port phy0
> Interface phy0
> type: dpdk
> options: {dpdk-devargs="5e:00.0"}
> 
> ~/ovs_scripts# $OVS_DIR/utilities/ovs-ofctl dump-flows br0
>  cookie=0x0, duration=29.466s, table=0, n_packets=0, n_bytes=0, in_port=phy0 
> actions=IN_PORT
> 
> I'm expecting the flow to be partially offloaded, but I get a segfault when 
> using the above branch. More info on the segfault below:
> 
> Thread 13 "pmd-c01/id:8" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7f9f72734700 (LWP 19327)]
> 0x56163bf0d825 in set_error (error=0x0, type=RTE_FLOW_ERROR_TYPE_ATTR) at 
> lib/netdev-dpdk.h:84
> (gdb) bt
> #0  0x56163bf0d825 in set_error (error=0x0, 
> type=RTE_FLOW_ERROR_TYPE_ATTR) at lib/netdev-dpdk.h:84
> #1  0x56163bf0d8d3 in netdev_dpdk_rte_flow_get_restore_info 
> (netdev=0x1bfc65c80, p=0x19033af00, info=0x7f9f72729a20, error=0x0) at 
> lib/netdev-dpdk.h:119
> #2  0x56163bf14da3 in netdev_offload_dpdk_hw_miss_packet_recover 
> (netdev=0x1bfc65c80, packet=0x19033af00) at lib/netdev-offload-dpdk.c:2133
> #3  0x56163bde3662 in netdev_hw_miss_packet_recover (netdev=0x1bfc65c80, 
> packet=0x19033af00) at lib/netdev-offload.c:265
> #4  0x56163bda19a9 in dp_netdev_hw_flow (pmd=0x7f9f72735010, port_no=2, 
> packet=0x19033af00, flow=0x7f9f72729b98) at lib/dpif-netdev.c:7087
> #5  0x56163bda1c5c in dfc_processing (pmd=0x7f9f72735010, 
> packets_=0x7f9f727310d0, keys=0x7f9f7272c480, missed_keys=0x7f9f7272c370, 
> batches=0x7f9f72729f60, n_batches=0x7f9f72730f70, flow_map=0x7f9f72729c50, 
> n_flows=0x7f9f72730f78, index_map=0x7f9f72729c30 "", md_is_valid=false, 
> port_no=2) at lib/dpif-netdev.c:7168
> #6  0x56163bda2f3e in dp_netdev_input__ (pmd=0x7f9f72735010, 
> packets=0x7f9f727310d0, md_is_valid=false, port_no=2) at 
> lib/dpif-netdev.c:7475
> #7  0x56163bda3105 in dp_netdev_input (pmd=0x7f9f72735010, 
> packets=0x7f9f727310d0, port_no=2) at lib/dpif-netdev.c:7519
> #8  0x56163bd9ab04 in dp_netdev_process_rxq_port (pmd=0x7f9f72735010, 
> rxq=0x56163fb3f610, port_no=2) at lib/dpif-netdev.c:4774
> #9  0x56163bd9ee17 in pmd_thread_main (f_=0x7f9f72735010) at 
> lib/dpif-netdev.c:6063
> #10 0x56163be71c88 in ovsthread_wrapper (aux_=0x56163fb3fe70) at 
> lib/ovs-thread.c:383
> #11 0x7f9f884cf6db in start_thread (arg=0x7f9f72734700) at 
> pthread_create.c:463
> #12 0x7f9f862bb71f in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
> 
> In netdev_offload_dpdk_hw_miss_packet_recover() calls 
> netdev_dpdk_rte_flow_get_restore_info() with a NULL for the struct 
> rte_flow_error *error argument:
> 
> if (netdev_dpdk_rte_flow_get_restore_info(netdev, packet,
>   _restore_info, NULL)) {
> /* This function is called for every packet, and in most cases there
>  * will be no restore info from the HW, thus error is expected.
>  */
> return 0;
> }
> 
> There are 2 "netdev_dpdk_rte_flow_get_restore_info()" functions. One in 
> lib/netdev-dpdk.h and one in lib/netdev-dpdk.c. 
> 
> I don't have the experimental API enabled, so I'm using 

Re: [ovs-dev] [PATCH V6 00/13] Netdev vxlan-decap offload

[Ferriter, Cian]

> -Original Message-
> From: dev  On Behalf Of Ferriter, Cian
> Sent: Wednesday 23 June 2021 13:38
> To: Ilya Maximets ; Eli Britstein ; 
> d...@openvswitch.org
> Cc: ivan.ma...@oktetlabs.ru; Ameer Mahagneh ; Majd Dibbiny 
> 
> Subject: Re: [ovs-dev] [PATCH V6 00/13] Netdev vxlan-decap offload
> 
> Hi all,
> 
> As part of rebasing our AVX512 DPIF on this patchset, I tested this patchset 
> with partial HWOL and I'm
> seeing strange behaviour.
> 
> I'll report back more detailed findings soon, just wanted to mention this 
> here as soon as I found the
> issue.
> 
> Thanks,
> Cian
> 

More details on the issue I'm seeing:
I'm using Ilya's branch from Github:
https://github.com/igsilya/ovs/tree/tmp-vxlan-decap

~/ovs_scripts# $OVS_DIR/utilities/ovs-vsctl list Open_vSwitch
dpdk_version: "DPDK 20.11.1"
other_config: {dpdk-hugepage-dir="/mnt/huge", dpdk-init="true", 
dpdk-lcore-mask="0x1", dpdk-socket-mem="2048,0", emc-insert-inv-prob="0", 
hw-offload="true", pmd-cpu-mask="0x2"}

~/ovs_scripts# $OVS_DIR/utilities/ovs-vsctl show
31584ce5-09c1-44b3-ab27-1a0308d63fff
Bridge br0
datapath_type: netdev
Port br0
Interface br0
type: internal
Port phy0
Interface phy0
type: dpdk
options: {dpdk-devargs="5e:00.0"}

~/ovs_scripts# $OVS_DIR/utilities/ovs-ofctl dump-flows br0
 cookie=0x0, duration=29.466s, table=0, n_packets=0, n_bytes=0, in_port=phy0 
actions=IN_PORT

I'm expecting the flow to be partially offloaded, but I get a segfault when 
using the above branch. More info on the segfault below:

Thread 13 "pmd-c01/id:8" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f9f72734700 (LWP 19327)]
0x56163bf0d825 in set_error (error=0x0, type=RTE_FLOW_ERROR_TYPE_ATTR) at 
lib/netdev-dpdk.h:84
(gdb) bt
#0  0x56163bf0d825 in set_error (error=0x0, type=RTE_FLOW_ERROR_TYPE_ATTR) 
at lib/netdev-dpdk.h:84
#1  0x56163bf0d8d3 in netdev_dpdk_rte_flow_get_restore_info 
(netdev=0x1bfc65c80, p=0x19033af00, info=0x7f9f72729a20, error=0x0) at 
lib/netdev-dpdk.h:119
#2  0x56163bf14da3 in netdev_offload_dpdk_hw_miss_packet_recover 
(netdev=0x1bfc65c80, packet=0x19033af00) at lib/netdev-offload-dpdk.c:2133
#3  0x56163bde3662 in netdev_hw_miss_packet_recover (netdev=0x1bfc65c80, 
packet=0x19033af00) at lib/netdev-offload.c:265
#4  0x56163bda19a9 in dp_netdev_hw_flow (pmd=0x7f9f72735010, port_no=2, 
packet=0x19033af00, flow=0x7f9f72729b98) at lib/dpif-netdev.c:7087
#5  0x56163bda1c5c in dfc_processing (pmd=0x7f9f72735010, 
packets_=0x7f9f727310d0, keys=0x7f9f7272c480, missed_keys=0x7f9f7272c370, 
batches=0x7f9f72729f60, n_batches=0x7f9f72730f70, flow_map=0x7f9f72729c50, 
n_flows=0x7f9f72730f78, index_map=0x7f9f72729c30 "", md_is_valid=false, 
port_no=2) at lib/dpif-netdev.c:7168
#6  0x56163bda2f3e in dp_netdev_input__ (pmd=0x7f9f72735010, 
packets=0x7f9f727310d0, md_is_valid=false, port_no=2) at lib/dpif-netdev.c:7475
#7  0x56163bda3105 in dp_netdev_input (pmd=0x7f9f72735010, 
packets=0x7f9f727310d0, port_no=2) at lib/dpif-netdev.c:7519
#8  0x56163bd9ab04 in dp_netdev_process_rxq_port (pmd=0x7f9f72735010, 
rxq=0x56163fb3f610, port_no=2) at lib/dpif-netdev.c:4774
#9  0x56163bd9ee17 in pmd_thread_main (f_=0x7f9f72735010) at 
lib/dpif-netdev.c:6063
#10 0x56163be71c88 in ovsthread_wrapper (aux_=0x56163fb3fe70) at 
lib/ovs-thread.c:383
#11 0x7f9f884cf6db in start_thread (arg=0x7f9f72734700) at 
pthread_create.c:463
#12 0x7f9f862bb71f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

In netdev_offload_dpdk_hw_miss_packet_recover() calls 
netdev_dpdk_rte_flow_get_restore_info() with a NULL for the struct 
rte_flow_error *error argument:

if (netdev_dpdk_rte_flow_get_restore_info(netdev, packet,
  _restore_info, NULL)) {
/* This function is called for every packet, and in most cases there
 * will be no restore info from the HW, thus error is expected.
 */
return 0;
}

There are 2 "netdev_dpdk_rte_flow_get_restore_info()" functions. One in 
lib/netdev-dpdk.h and one in lib/netdev-dpdk.c. 

I don't have the experimental API enabled, so I'm using the function rom 
lib/netdev-dpdk.h. 

> > -Original Message-
> > From: dev  On Behalf Of Ilya Maximets
> > Sent: Tuesday 22 June 2021 16:55
> > To: Eli Britstein ; d...@openvswitch.org; Ilya Maximets 
> > 
> > Cc: ivan.ma...@oktetlabs.ru; Ameer Mahagneh ; Majd 
> > Dibbiny 
> > Subject: Re: [ovs-dev] [PATCH V6 00/13] Netdev vxlan-decap offload
> >
> > On 4/4/21 11:54 AM, Eli Britstein wrote:
> > > VXLAN decap in OVS-DPDK configuration consists of two flows:
&

Re: [ovs-dev] [PATCH V6 00/13] Netdev vxlan-decap offload

[Ferriter, Cian]

Hi all,

As part of rebasing our AVX512 DPIF on this patchset, I tested this patchset 
with partial HWOL and I'm seeing strange behaviour.

I'll report back more detailed findings soon, just wanted to mention this here 
as soon as I found the issue.

Thanks,
Cian

> -Original Message-
> From: dev  On Behalf Of Ilya Maximets
> Sent: Tuesday 22 June 2021 16:55
> To: Eli Britstein ; d...@openvswitch.org; Ilya Maximets 
> 
> Cc: ivan.ma...@oktetlabs.ru; Ameer Mahagneh ; Majd Dibbiny 
> 
> Subject: Re: [ovs-dev] [PATCH V6 00/13] Netdev vxlan-decap offload
> 
> On 4/4/21 11:54 AM, Eli Britstein wrote:
> > VXLAN decap in OVS-DPDK configuration consists of two flows:
> > F1: in_port(ens1f0),eth(),ipv4(),udp(), actions:tnl_pop(vxlan_sys_4789)
> > F2: tunnel(),in_port(vxlan_sys_4789),eth(),ipv4(), actions:ens1f0_0
> >
> > F1 is a classification flow. It has outer headers matches and it
> > classifies the packet as a VXLAN packet, and using tnl_pop action the
> > packet continues processing in F2.
> > F2 is a flow that has matches on tunnel metadata as well as on the inner
> > packet headers (as any other flow).
> >
> > In order to fully offload VXLAN decap path, both F1 and F2 should be
> > offloaded. As there are more than one flow in HW, it is possible that
> > F1 is done by HW but F2 is not. Packet is received by SW, and should be
> > processed starting from F2 as F1 was already done by HW.
> > Rte_flows are applicable only on physical port IDs. Keeping the original
> > physical in port on which the packet is received on enables applying
> > vport flows (e.g. F2) on that physical port.
> >
> > This patch-set makes use of [1] introduced in DPDK 20.11, that adds API
> > for tunnel offloads.
> >
> > Note that MLX5 PMD has a bug that the tnl_pop private actions must be
> > first. In OVS it is not.
> > Fixing this issue is scheduled for 21.05 (and stable 20.11.2).
> > Meanwhile, tests were done with a workaround for it [2].
> >
> > v2-v1:
> > - Tracking original in_port, and applying vport on that physical port 
> > instead of all PFs.
> > v3-v2:
> > - Traversing ports using a new API instead of flow_dump.
> > - Refactor packet state recover logic, with bug fix for error pop_header.
> > - One ref count for netdev in non-tunnel case.
> > - Rename variables, comments, rebase.
> > v4-v3:
> > - Extract orig_in_port from physdev for flow modify.
> > - Miss handling fixes.
> > v5-v4:
> > - Drop refactor offload rule creation commit.
> > - Comment about setting in_port in restore.
> > - Refactor vports flow offload commit.
> > v6-v5:
> > - Fixed duplicate netdev ref bug.
> >
> > Travis:
> > v1: https://travis-ci.org/github/elibritstein/OVS/builds/756418552
> > v2: https://travis-ci.org/github/elibritstein/OVS/builds/758382963
> > v3: https://travis-ci.org/github/elibritstein/OVS/builds/761089087
> > v4: https://travis-ci.org/github/elibritstein/OVS/builds/763146966
> > v5: https://travis-ci.org/github/elibritstein/OVS/builds/765271879
> > v6: https://travis-ci.org/github/elibritstein/OVS/builds/765816800
> >
> > GitHub Actions:
> > v1: https://github.com/elibritstein/OVS/actions/runs/515334647
> > v2: https://github.com/elibritstein/OVS/actions/runs/554986007
> > v3: https://github.com/elibritstein/OVS/actions/runs/613226225
> > v4: https://github.com/elibritstein/OVS/actions/runs/658415274
> > v5: https://github.com/elibritstein/OVS/actions/runs/704357369
> > v6: https://github.com/elibritstein/OVS/actions/runs/716304028
> >
> > [1] https://mails.dpdk.org/archives/dev/2020-October/187314.html
> > [2] https://github.com/elibritstein/dpdk-stable/pull/1
> >
> >
> > Eli Britstein (10):
> >   netdev-offload: Add HW miss packet state recover API
> >   netdev-dpdk: Introduce DPDK tunnel APIs
> >   netdev-offload: Introduce an API to traverse ports
> >   netdev-dpdk: Add flow_api support for netdev vxlan vports
> >   netdev-offload-dpdk: Implement HW miss packet recover for vport
> >   dpif-netdev: Add HW miss packet state recover logic
> >   netdev-offload-dpdk: Change log rate limits
> >   netdev-offload-dpdk: Support tunnel pop action
> >   netdev-offload-dpdk: Support vports flows offload
> >   netdev-dpdk-offload: Add vxlan pattern matching function
> >
> > Ilya Maximets (2):
> >   netdev-offload: Allow offloading to netdev without ifindex.
> >   netdev-offload: Disallow offloading to unrelated tunneling vports.
> >
> > Sriharsha Basavapatna (1):
> >   dpif-netdev: Provide orig_in_port in metadata

Re: [ovs-dev] [PATCH V6 00/13] Netdev vxlan-decap offload

[Ilya Maximets]

On 4/4/21 11:54 AM, Eli Britstein wrote:
> VXLAN decap in OVS-DPDK configuration consists of two flows:
> F1: in_port(ens1f0),eth(),ipv4(),udp(), actions:tnl_pop(vxlan_sys_4789)
> F2: tunnel(),in_port(vxlan_sys_4789),eth(),ipv4(), actions:ens1f0_0
> 
> F1 is a classification flow. It has outer headers matches and it
> classifies the packet as a VXLAN packet, and using tnl_pop action the
> packet continues processing in F2.
> F2 is a flow that has matches on tunnel metadata as well as on the inner
> packet headers (as any other flow).
> 
> In order to fully offload VXLAN decap path, both F1 and F2 should be
> offloaded. As there are more than one flow in HW, it is possible that
> F1 is done by HW but F2 is not. Packet is received by SW, and should be
> processed starting from F2 as F1 was already done by HW.
> Rte_flows are applicable only on physical port IDs. Keeping the original
> physical in port on which the packet is received on enables applying
> vport flows (e.g. F2) on that physical port.
> 
> This patch-set makes use of [1] introduced in DPDK 20.11, that adds API
> for tunnel offloads.
> 
> Note that MLX5 PMD has a bug that the tnl_pop private actions must be
> first. In OVS it is not.
> Fixing this issue is scheduled for 21.05 (and stable 20.11.2).
> Meanwhile, tests were done with a workaround for it [2].
> 
> v2-v1:
> - Tracking original in_port, and applying vport on that physical port instead 
> of all PFs.
> v3-v2:
> - Traversing ports using a new API instead of flow_dump.
> - Refactor packet state recover logic, with bug fix for error pop_header.
> - One ref count for netdev in non-tunnel case.
> - Rename variables, comments, rebase.
> v4-v3:
> - Extract orig_in_port from physdev for flow modify.
> - Miss handling fixes.
> v5-v4:
> - Drop refactor offload rule creation commit.
> - Comment about setting in_port in restore.
> - Refactor vports flow offload commit.
> v6-v5:
> - Fixed duplicate netdev ref bug.
> 
> Travis:
> v1: https://travis-ci.org/github/elibritstein/OVS/builds/756418552
> v2: https://travis-ci.org/github/elibritstein/OVS/builds/758382963
> v3: https://travis-ci.org/github/elibritstein/OVS/builds/761089087
> v4: https://travis-ci.org/github/elibritstein/OVS/builds/763146966
> v5: https://travis-ci.org/github/elibritstein/OVS/builds/765271879
> v6: https://travis-ci.org/github/elibritstein/OVS/builds/765816800
> 
> GitHub Actions:
> v1: https://github.com/elibritstein/OVS/actions/runs/515334647
> v2: https://github.com/elibritstein/OVS/actions/runs/554986007
> v3: https://github.com/elibritstein/OVS/actions/runs/613226225
> v4: https://github.com/elibritstein/OVS/actions/runs/658415274
> v5: https://github.com/elibritstein/OVS/actions/runs/704357369
> v6: https://github.com/elibritstein/OVS/actions/runs/716304028
> 
> [1] https://mails.dpdk.org/archives/dev/2020-October/187314.html
> [2] https://github.com/elibritstein/dpdk-stable/pull/1
> 
> 
> Eli Britstein (10):
>   netdev-offload: Add HW miss packet state recover API
>   netdev-dpdk: Introduce DPDK tunnel APIs
>   netdev-offload: Introduce an API to traverse ports
>   netdev-dpdk: Add flow_api support for netdev vxlan vports
>   netdev-offload-dpdk: Implement HW miss packet recover for vport
>   dpif-netdev: Add HW miss packet state recover logic
>   netdev-offload-dpdk: Change log rate limits
>   netdev-offload-dpdk: Support tunnel pop action
>   netdev-offload-dpdk: Support vports flows offload
>   netdev-dpdk-offload: Add vxlan pattern matching function
> 
> Ilya Maximets (2):
>   netdev-offload: Allow offloading to netdev without ifindex.
>   netdev-offload: Disallow offloading to unrelated tunneling vports.
> 
> Sriharsha Basavapatna (1):
>   dpif-netdev: Provide orig_in_port in metadata for tunneled packets
> 
>  Documentation/howto/dpdk.rst  |   1 +
>  NEWS  |   2 +
>  lib/dpif-netdev.c |  97 +++--
>  lib/netdev-dpdk.c | 118 ++
>  lib/netdev-dpdk.h | 106 -
>  lib/netdev-offload-dpdk.c | 704 +++---
>  lib/netdev-offload-provider.h |   5 +
>  lib/netdev-offload-tc.c   |   8 +
>  lib/netdev-offload.c  |  47 ++-
>  lib/netdev-offload.h  |  10 +
>  lib/packets.h |   8 +-
>  11 files changed, 1022 insertions(+), 84 deletions(-)
> 

Hi.  I reviewed the whole series and it looks mostly OK to me.
I made a several changes along the way and below you may find a diff
of what I changed.  In short:

 - Some style fixes: style of function prototypes and a way how long
   function calls wrapped.  Added names to uint32_t arguments to
   function prototypes.

 - Clarified hw_miss_packet_recover() API.  It needs a note that it
   takes ownership of a packet on error.  Fixed 'return -1' which
   doesn't comply with the API definition (should return positive
   errno).

 - Moved NEWS updates to correct place.

 - Added a packet drop counter.

 - Refactored changes in dfc_processing().  Basically, 

Re: [ovs-dev] [PATCH V6 00/13] Netdev vxlan-decap offload

[Gaëtan Rivet]

On Wed, Apr 21, 2021, at 10:20, Kovacevic, Marko wrote:
> > On 4/7/2021 12:10 PM, Sriharsha Basavapatna wrote:
> > >
> > > On Sun, Apr 4, 2021 at 3:25 PM Eli Britstein  > > > wrote:
> > >
> > > VXLAN decap in OVS-DPDK configuration consists of two flows:
> > > F1: in_port(ens1f0),eth(),ipv4(),udp(),
> > > actions:tnl_pop(vxlan_sys_4789)
> > > F2: tunnel(),in_port(vxlan_sys_4789),eth(),ipv4(), actions:ens1f0_0
> > >
> > > F1 is a classification flow. It has outer headers matches and it
> > > classifies the packet as a VXLAN packet, and using tnl_pop action the
> > > packet continues processing in F2.
> > > F2 is a flow that has matches on tunnel metadata as well as on the
> > > inner
> > > packet headers (as any other flow).
> > >
> > > In order to fully offload VXLAN decap path, both F1 and F2 should be
> > > offloaded. As there are more than one flow in HW, it is possible that
> > > F1 is done by HW but F2 is not. Packet is received by SW, and
> > > should be
> > > processed starting from F2 as F1 was already done by HW.
> > > Rte_flows are applicable only on physical port IDs. Keeping the
> > > original
> > > physical in port on which the packet is received on enables applying
> > > vport flows (e.g. F2) on that physical port.
> > >
> > > This patch-set makes use of [1] introduced in DPDK 20.11, that
> > > adds API
> > > for tunnel offloads.
> > >
> > > Note that MLX5 PMD has a bug that the tnl_pop private actions must be
> > > first. In OVS it is not.
> > > Fixing this issue is scheduled for 21.05 (and stable 20.11.2).
> > > Meanwhile, tests were done with a workaround for it [2].
> > >
> > > v2-v1:
> > > - Tracking original in_port, and applying vport on that physical
> > > port instead of all PFs.
> > > v3-v2:
> > > - Traversing ports using a new API instead of flow_dump.
> > > - Refactor packet state recover logic, with bug fix for error
> > > pop_header.
> > > - One ref count for netdev in non-tunnel case.
> > > - Rename variables, comments, rebase.
> > > v4-v3:
> > > - Extract orig_in_port from physdev for flow modify.
> > > - Miss handling fixes.
> > > v5-v4:
> > > - Drop refactor offload rule creation commit.
> > > - Comment about setting in_port in restore.
> > > - Refactor vports flow offload commit.
> > > v6-v5:
> > > - Fixed duplicate netdev ref bug.
> > >
> > >
> > > Can you provide some info on this bug ?  and what changes were done to
> > > fix this ?
> > 
> > With v5, the 2 netdevs sent to ufid_to_rte_flow_associate are always
> > non-NULL (was not like this previously), and there was this line:
> > 
> > +    data->netdev = vport ? netdev_ref(vport) : physdev;
> > 
> > As the "vport" was always non-null, even for non-tunnels, it took
> > another ref of it, but in disassociate, only one close was done.
> > 
> > With v6 it is like this (changed arguments names a bit)
> > 
> > +    data->physdev = netdev != physdev ? netdev_ref(physdev) : physdev;
> > 
> > Checking the netdevs are different, not non-NULL.
> > 
> > > Thanks,
> > > -Harsha
> > >
> > >
> > > Travis:
> > > v1: https://travis-ci.org/github/elibritstein/OVS/builds/756418552
> > > v2
> > > :
> > > https://travis-ci.org/github/elibritstein/OVS/builds/758382963
> > > v3
> > > :
> > > https://travis-ci.org/github/elibritstein/OVS/builds/761089087
> > > v4
> > > :
> > > https://travis-ci.org/github/elibritstein/OVS/builds/763146966
> > > v5
> > > :
> > > https://travis-ci.org/github/elibritstein/OVS/builds/765271879
> > > v6
> > > :
> > > https://travis-ci.org/github/elibritstein/OVS/builds/765816800
> > > 
> > >
> > > GitHub Actions:
> > > v1: https://github.com/elibritstein/OVS/actions/runs/515334647
> > > 
> > > v2: https://github.com/elibritstein/OVS/actions/runs/554986007
> > > 
> > > v3: https://github.com/elibritstein/OVS/actions/runs/613226225
> > > 
> > > v4: https://github.com/elibritstein/OVS/actions/runs/658415274
> > > 
> > > v5: https://github.com/elibritstein/OVS/actions/runs/704357369
> > > 
> > > v6: 

Re: [ovs-dev] [PATCH V6 00/13] Netdev vxlan-decap offload

[Kovacevic, Marko]

> On 4/7/2021 12:10 PM, Sriharsha Basavapatna wrote:
> >
> > On Sun, Apr 4, 2021 at 3:25 PM Eli Britstein  > > wrote:
> >
> > VXLAN decap in OVS-DPDK configuration consists of two flows:
> > F1: in_port(ens1f0),eth(),ipv4(),udp(),
> > actions:tnl_pop(vxlan_sys_4789)
> > F2: tunnel(),in_port(vxlan_sys_4789),eth(),ipv4(), actions:ens1f0_0
> >
> > F1 is a classification flow. It has outer headers matches and it
> > classifies the packet as a VXLAN packet, and using tnl_pop action the
> > packet continues processing in F2.
> > F2 is a flow that has matches on tunnel metadata as well as on the
> > inner
> > packet headers (as any other flow).
> >
> > In order to fully offload VXLAN decap path, both F1 and F2 should be
> > offloaded. As there are more than one flow in HW, it is possible that
> > F1 is done by HW but F2 is not. Packet is received by SW, and
> > should be
> > processed starting from F2 as F1 was already done by HW.
> > Rte_flows are applicable only on physical port IDs. Keeping the
> > original
> > physical in port on which the packet is received on enables applying
> > vport flows (e.g. F2) on that physical port.
> >
> > This patch-set makes use of [1] introduced in DPDK 20.11, that
> > adds API
> > for tunnel offloads.
> >
> > Note that MLX5 PMD has a bug that the tnl_pop private actions must be
> > first. In OVS it is not.
> > Fixing this issue is scheduled for 21.05 (and stable 20.11.2).
> > Meanwhile, tests were done with a workaround for it [2].
> >
> > v2-v1:
> > - Tracking original in_port, and applying vport on that physical
> > port instead of all PFs.
> > v3-v2:
> > - Traversing ports using a new API instead of flow_dump.
> > - Refactor packet state recover logic, with bug fix for error
> > pop_header.
> > - One ref count for netdev in non-tunnel case.
> > - Rename variables, comments, rebase.
> > v4-v3:
> > - Extract orig_in_port from physdev for flow modify.
> > - Miss handling fixes.
> > v5-v4:
> > - Drop refactor offload rule creation commit.
> > - Comment about setting in_port in restore.
> > - Refactor vports flow offload commit.
> > v6-v5:
> > - Fixed duplicate netdev ref bug.
> >
> >
> > Can you provide some info on this bug ?  and what changes were done to
> > fix this ?
> 
> With v5, the 2 netdevs sent to ufid_to_rte_flow_associate are always
> non-NULL (was not like this previously), and there was this line:
> 
> +    data->netdev = vport ? netdev_ref(vport) : physdev;
> 
> As the "vport" was always non-null, even for non-tunnels, it took
> another ref of it, but in disassociate, only one close was done.
> 
> With v6 it is like this (changed arguments names a bit)
> 
> +    data->physdev = netdev != physdev ? netdev_ref(physdev) : physdev;
> 
> Checking the netdevs are different, not non-NULL.
> 
> > Thanks,
> > -Harsha
> >
> >
> > Travis:
> > v1: https://travis-ci.org/github/elibritstein/OVS/builds/756418552
> > v2
> > :
> > https://travis-ci.org/github/elibritstein/OVS/builds/758382963
> > v3
> > :
> > https://travis-ci.org/github/elibritstein/OVS/builds/761089087
> > v4
> > :
> > https://travis-ci.org/github/elibritstein/OVS/builds/763146966
> > v5
> > :
> > https://travis-ci.org/github/elibritstein/OVS/builds/765271879
> > v6
> > :
> > https://travis-ci.org/github/elibritstein/OVS/builds/765816800
> > 
> >
> > GitHub Actions:
> > v1: https://github.com/elibritstein/OVS/actions/runs/515334647
> > 
> > v2: https://github.com/elibritstein/OVS/actions/runs/554986007
> > 
> > v3: https://github.com/elibritstein/OVS/actions/runs/613226225
> > 
> > v4: https://github.com/elibritstein/OVS/actions/runs/658415274
> > 
> > v5: https://github.com/elibritstein/OVS/actions/runs/704357369
> > 
> > v6: https://github.com/elibritstein/OVS/actions/runs/716304028
> > 
> >
> > [1] https://mails.dpdk.org/archives/dev/2020-October/187314.html
> > 
> > [2] 

Re: [ovs-dev] [PATCH V6 00/13] Netdev vxlan-decap offload

[Finn, Emma]

> -Original Message-
> From: dev  On Behalf Of Sriharsha
> Basavapatna via dev
> Sent: Thursday 8 April 2021 18:04
> To: Eli Britstein 
> Cc: ovs dev ; ivan.ma...@oktetlabs.ru; Ilya
> Maximets ; Ameer Mahagneh
> ; Majd Dibbiny 
> Subject: Re: [ovs-dev] [PATCH V6 00/13] Netdev vxlan-decap offload
> 
> On Wed, Apr 7, 2021 at 2:50 PM Eli Britstein  wrote:
> 
> >
> > On 4/7/2021 12:10 PM, Sriharsha Basavapatna wrote:
> >
> >
> > On Sun, Apr 4, 2021 at 3:25 PM Eli Britstein  wrote:
> >
> >> VXLAN decap in OVS-DPDK configuration consists of two flows:
> >> F1: in_port(ens1f0),eth(),ipv4(),udp(),
> >> actions:tnl_pop(vxlan_sys_4789)
> >> F2: tunnel(),in_port(vxlan_sys_4789),eth(),ipv4(), actions:ens1f0_0
> >>
> >> F1 is a classification flow. It has outer headers matches and it
> >> classifies the packet as a VXLAN packet, and using tnl_pop action the
> >> packet continues processing in F2.
> >> F2 is a flow that has matches on tunnel metadata as well as on the
> >> inner packet headers (as any other flow).
> >>
> >> In order to fully offload VXLAN decap path, both F1 and F2 should be
> >> offloaded. As there are more than one flow in HW, it is possible that
> >> F1 is done by HW but F2 is not. Packet is received by SW, and should
> >> be processed starting from F2 as F1 was already done by HW.
> >> Rte_flows are applicable only on physical port IDs. Keeping the
> >> original physical in port on which the packet is received on enables
> >> applying vport flows (e.g. F2) on that physical port.
> >>
> >> This patch-set makes use of [1] introduced in DPDK 20.11, that adds
> >> API for tunnel offloads.
> >>
> >> Note that MLX5 PMD has a bug that the tnl_pop private actions must be
> >> first. In OVS it is not.
> >> Fixing this issue is scheduled for 21.05 (and stable 20.11.2).
> >> Meanwhile, tests were done with a workaround for it [2].
> >>
> >> v2-v1:
> >> - Tracking original in_port, and applying vport on that physical port
> >> instead of all PFs.
> >> v3-v2:
> >> - Traversing ports using a new API instead of flow_dump.
> >> - Refactor packet state recover logic, with bug fix for error pop_header.
> >> - One ref count for netdev in non-tunnel case.
> >> - Rename variables, comments, rebase.
> >> v4-v3:
> >> - Extract orig_in_port from physdev for flow modify.
> >> - Miss handling fixes.
> >> v5-v4:
> >> - Drop refactor offload rule creation commit.
> >> - Comment about setting in_port in restore.
> >> - Refactor vports flow offload commit.
> >> v6-v5:
> >> - Fixed duplicate netdev ref bug.
> >>
> >
> > Can you provide some info on this bug ?  and what changes were done to
> > fix this ?
> >
> > With v5, the 2 netdevs sent to ufid_to_rte_flow_associate are always
> > non-NULL (was not like this previously), and there was this line:
> >
> > +data->netdev = vport ? netdev_ref(vport) : physdev;
> >
> > As the "vport" was always non-null, even for non-tunnels, it took
> > another ref of it, but in disassociate, only one close was done.
> >
> > With v6 it is like this (changed arguments names a bit)
> >
> > +data->physdev = netdev != physdev ? netdev_ref(physdev) :
> > + physdev;
> >
> > Checking the netdevs are different, not non-NULL.
> >
> > Thanks,
> > -Harsha
> >
> >>
> >> Travis:
> >> v1: https://travis-ci.org/github/elibritstein/OVS/builds/756418552
> >> v2 <https://travis-ci.org/github/elibritstein/OVS/builds/756418552v2>:
> >> https://travis-ci.org/github/elibritstein/OVS/builds/758382963
> >> v3 <https://travis-ci.org/github/elibritstein/OVS/builds/758382963v3>:
> >> https://travis-ci.org/github/elibritstein/OVS/builds/761089087
> >> v4 <https://travis-ci.org/github/elibritstein/OVS/builds/761089087v4>:
> >> https://travis-ci.org/github/elibritstein/OVS/builds/763146966
> >> v5 <https://travis-ci.org/github/elibritstein/OVS/builds/763146966v5>:
> >> https://travis-ci.org/github/elibritstein/OVS/builds/765271879
> >> v6 <https://travis-ci.org/github/elibritstein/OVS/builds/765271879v6>:
> >> https://travis-ci.org/github/elibritstein/OVS/builds/765816800
> >>
> >> GitHub Actions:
> >> v1: https://github.com/elibritstein/OVS/actions/runs/515334647
> >> v2: https://github.com/elibritstein/OVS/ac

Re: [ovs-dev] [PATCH V6 00/13] Netdev vxlan-decap offload

[Sriharsha Basavapatna via dev]

On Wed, Apr 7, 2021 at 2:50 PM Eli Britstein  wrote:

>
> On 4/7/2021 12:10 PM, Sriharsha Basavapatna wrote:
>
>
> On Sun, Apr 4, 2021 at 3:25 PM Eli Britstein  wrote:
>
>> VXLAN decap in OVS-DPDK configuration consists of two flows:
>> F1: in_port(ens1f0),eth(),ipv4(),udp(), actions:tnl_pop(vxlan_sys_4789)
>> F2: tunnel(),in_port(vxlan_sys_4789),eth(),ipv4(), actions:ens1f0_0
>>
>> F1 is a classification flow. It has outer headers matches and it
>> classifies the packet as a VXLAN packet, and using tnl_pop action the
>> packet continues processing in F2.
>> F2 is a flow that has matches on tunnel metadata as well as on the inner
>> packet headers (as any other flow).
>>
>> In order to fully offload VXLAN decap path, both F1 and F2 should be
>> offloaded. As there are more than one flow in HW, it is possible that
>> F1 is done by HW but F2 is not. Packet is received by SW, and should be
>> processed starting from F2 as F1 was already done by HW.
>> Rte_flows are applicable only on physical port IDs. Keeping the original
>> physical in port on which the packet is received on enables applying
>> vport flows (e.g. F2) on that physical port.
>>
>> This patch-set makes use of [1] introduced in DPDK 20.11, that adds API
>> for tunnel offloads.
>>
>> Note that MLX5 PMD has a bug that the tnl_pop private actions must be
>> first. In OVS it is not.
>> Fixing this issue is scheduled for 21.05 (and stable 20.11.2).
>> Meanwhile, tests were done with a workaround for it [2].
>>
>> v2-v1:
>> - Tracking original in_port, and applying vport on that physical port
>> instead of all PFs.
>> v3-v2:
>> - Traversing ports using a new API instead of flow_dump.
>> - Refactor packet state recover logic, with bug fix for error pop_header.
>> - One ref count for netdev in non-tunnel case.
>> - Rename variables, comments, rebase.
>> v4-v3:
>> - Extract orig_in_port from physdev for flow modify.
>> - Miss handling fixes.
>> v5-v4:
>> - Drop refactor offload rule creation commit.
>> - Comment about setting in_port in restore.
>> - Refactor vports flow offload commit.
>> v6-v5:
>> - Fixed duplicate netdev ref bug.
>>
>
> Can you provide some info on this bug ?  and what changes were done to fix
> this ?
>
> With v5, the 2 netdevs sent to ufid_to_rte_flow_associate are always
> non-NULL (was not like this previously), and there was this line:
>
> +data->netdev = vport ? netdev_ref(vport) : physdev;
>
> As the "vport" was always non-null, even for non-tunnels, it took another
> ref of it, but in disassociate, only one close was done.
>
> With v6 it is like this (changed arguments names a bit)
>
> +data->physdev = netdev != physdev ? netdev_ref(physdev) : physdev;
>
> Checking the netdevs are different, not non-NULL.
>
> Thanks,
> -Harsha
>
>>
>> Travis:
>> v1: https://travis-ci.org/github/elibritstein/OVS/builds/756418552
>> v2 :
>> https://travis-ci.org/github/elibritstein/OVS/builds/758382963
>> v3 :
>> https://travis-ci.org/github/elibritstein/OVS/builds/761089087
>> v4 :
>> https://travis-ci.org/github/elibritstein/OVS/builds/763146966
>> v5 :
>> https://travis-ci.org/github/elibritstein/OVS/builds/765271879
>> v6 :
>> https://travis-ci.org/github/elibritstein/OVS/builds/765816800
>>
>> GitHub Actions:
>> v1: https://github.com/elibritstein/OVS/actions/runs/515334647
>> v2: https://github.com/elibritstein/OVS/actions/runs/554986007
>> v3: https://github.com/elibritstein/OVS/actions/runs/613226225
>> v4: https://github.com/elibritstein/OVS/actions/runs/658415274
>> v5: https://github.com/elibritstein/OVS/actions/runs/704357369
>> v6: https://github.com/elibritstein/OVS/actions/runs/716304028
>>
>> [1] https://mails.dpdk.org/archives/dev/2020-October/187314.html
>> [2] https://github.com/elibritstein/dpdk-stable/pull/1
>>
>>
>> Eli Britstein (10):
>>   netdev-offload: Add HW miss packet state recover API
>>   netdev-dpdk: Introduce DPDK tunnel APIs
>>   netdev-offload: Introduce an API to traverse ports
>>   netdev-dpdk: Add flow_api support for netdev vxlan vports
>>   netdev-offload-dpdk: Implement HW miss packet recover for vport
>>   dpif-netdev: Add HW miss packet state recover logic
>>   netdev-offload-dpdk: Change log rate limits
>>   netdev-offload-dpdk: Support tunnel pop action
>>   netdev-offload-dpdk: Support vports flows offload
>>   netdev-dpdk-offload: Add vxlan pattern matching function
>>
>> Ilya Maximets (2):
>>   netdev-offload: Allow offloading to netdev without ifindex.
>>   netdev-offload: Disallow offloading to unrelated tunneling vports.
>>
>> Sriharsha Basavapatna (1):
>>   dpif-netdev: Provide orig_in_port in metadata for tunneled packets
>>
>>  Documentation/howto/dpdk.rst  |  

Re: [ovs-dev] [PATCH V6 00/13] Netdev vxlan-decap offload

[Eli Britstein]

On 4/7/2021 12:10 PM, Sriharsha Basavapatna wrote:


On Sun, Apr 4, 2021 at 3:25 PM Eli Britstein > wrote:


VXLAN decap in OVS-DPDK configuration consists of two flows:
F1: in_port(ens1f0),eth(),ipv4(),udp(),
actions:tnl_pop(vxlan_sys_4789)
F2: tunnel(),in_port(vxlan_sys_4789),eth(),ipv4(), actions:ens1f0_0

F1 is a classification flow. It has outer headers matches and it
classifies the packet as a VXLAN packet, and using tnl_pop action the
packet continues processing in F2.
F2 is a flow that has matches on tunnel metadata as well as on the
inner
packet headers (as any other flow).

In order to fully offload VXLAN decap path, both F1 and F2 should be
offloaded. As there are more than one flow in HW, it is possible that
F1 is done by HW but F2 is not. Packet is received by SW, and
should be
processed starting from F2 as F1 was already done by HW.
Rte_flows are applicable only on physical port IDs. Keeping the
original
physical in port on which the packet is received on enables applying
vport flows (e.g. F2) on that physical port.

This patch-set makes use of [1] introduced in DPDK 20.11, that
adds API
for tunnel offloads.

Note that MLX5 PMD has a bug that the tnl_pop private actions must be
first. In OVS it is not.
Fixing this issue is scheduled for 21.05 (and stable 20.11.2).
Meanwhile, tests were done with a workaround for it [2].

v2-v1:
- Tracking original in_port, and applying vport on that physical
port instead of all PFs.
v3-v2:
- Traversing ports using a new API instead of flow_dump.
- Refactor packet state recover logic, with bug fix for error
pop_header.
- One ref count for netdev in non-tunnel case.
- Rename variables, comments, rebase.
v4-v3:
- Extract orig_in_port from physdev for flow modify.
- Miss handling fixes.
v5-v4:
- Drop refactor offload rule creation commit.
- Comment about setting in_port in restore.
- Refactor vports flow offload commit.
v6-v5:
- Fixed duplicate netdev ref bug.


Can you provide some info on this bug ?  and what changes were done to 
fix this ?


With v5, the 2 netdevs sent to ufid_to_rte_flow_associate are always 
non-NULL (was not like this previously), and there was this line:


+    data->netdev = vport ? netdev_ref(vport) : physdev;

As the "vport" was always non-null, even for non-tunnels, it took 
another ref of it, but in disassociate, only one close was done.


With v6 it is like this (changed arguments names a bit)

+    data->physdev = netdev != physdev ? netdev_ref(physdev) : physdev;

Checking the netdevs are different, not non-NULL.


Thanks,
-Harsha


Travis:
v1: https://travis-ci.org/github/elibritstein/OVS/builds/756418552
v2
:
https://travis-ci.org/github/elibritstein/OVS/builds/758382963
v3
:
https://travis-ci.org/github/elibritstein/OVS/builds/761089087
v4
:
https://travis-ci.org/github/elibritstein/OVS/builds/763146966
v5
:
https://travis-ci.org/github/elibritstein/OVS/builds/765271879
v6
:
https://travis-ci.org/github/elibritstein/OVS/builds/765816800


GitHub Actions:
v1: https://github.com/elibritstein/OVS/actions/runs/515334647

v2: https://github.com/elibritstein/OVS/actions/runs/554986007

v3: https://github.com/elibritstein/OVS/actions/runs/613226225

v4: https://github.com/elibritstein/OVS/actions/runs/658415274

v5: https://github.com/elibritstein/OVS/actions/runs/704357369

v6: https://github.com/elibritstein/OVS/actions/runs/716304028


[1] https://mails.dpdk.org/archives/dev/2020-October/187314.html

[2] https://github.com/elibritstein/dpdk-stable/pull/1



Eli Britstein (10):
  netdev-offload: Add HW miss packet state recover API
  netdev-dpdk: Introduce DPDK tunnel APIs
  netdev-offload: Introduce an API to traverse ports
  netdev-dpdk: Add flow_api support for netdev vxlan vports
  netdev-offload-dpdk: Implement HW 

Re: [ovs-dev] [PATCH V6 00/13] Netdev vxlan-decap offload

[Sriharsha Basavapatna via dev]

On Sun, Apr 4, 2021 at 3:25 PM Eli Britstein  wrote:

> VXLAN decap in OVS-DPDK configuration consists of two flows:
> F1: in_port(ens1f0),eth(),ipv4(),udp(), actions:tnl_pop(vxlan_sys_4789)
> F2: tunnel(),in_port(vxlan_sys_4789),eth(),ipv4(), actions:ens1f0_0
>
> F1 is a classification flow. It has outer headers matches and it
> classifies the packet as a VXLAN packet, and using tnl_pop action the
> packet continues processing in F2.
> F2 is a flow that has matches on tunnel metadata as well as on the inner
> packet headers (as any other flow).
>
> In order to fully offload VXLAN decap path, both F1 and F2 should be
> offloaded. As there are more than one flow in HW, it is possible that
> F1 is done by HW but F2 is not. Packet is received by SW, and should be
> processed starting from F2 as F1 was already done by HW.
> Rte_flows are applicable only on physical port IDs. Keeping the original
> physical in port on which the packet is received on enables applying
> vport flows (e.g. F2) on that physical port.
>
> This patch-set makes use of [1] introduced in DPDK 20.11, that adds API
> for tunnel offloads.
>
> Note that MLX5 PMD has a bug that the tnl_pop private actions must be
> first. In OVS it is not.
> Fixing this issue is scheduled for 21.05 (and stable 20.11.2).
> Meanwhile, tests were done with a workaround for it [2].
>
> v2-v1:
> - Tracking original in_port, and applying vport on that physical port
> instead of all PFs.
> v3-v2:
> - Traversing ports using a new API instead of flow_dump.
> - Refactor packet state recover logic, with bug fix for error pop_header.
> - One ref count for netdev in non-tunnel case.
> - Rename variables, comments, rebase.
> v4-v3:
> - Extract orig_in_port from physdev for flow modify.
> - Miss handling fixes.
> v5-v4:
> - Drop refactor offload rule creation commit.
> - Comment about setting in_port in restore.
> - Refactor vports flow offload commit.
> v6-v5:
> - Fixed duplicate netdev ref bug.
>

Can you provide some info on this bug ?  and what changes were done to fix
this ?
Thanks,
-Harsha

>
> Travis:
> v1: https://travis-ci.org/github/elibritstein/OVS/builds/756418552
> v2 :
> https://travis-ci.org/github/elibritstein/OVS/builds/758382963
> v3 :
> https://travis-ci.org/github/elibritstein/OVS/builds/761089087
> v4 :
> https://travis-ci.org/github/elibritstein/OVS/builds/763146966
> v5 :
> https://travis-ci.org/github/elibritstein/OVS/builds/765271879
> v6 :
> https://travis-ci.org/github/elibritstein/OVS/builds/765816800
>
> GitHub Actions:
> v1: https://github.com/elibritstein/OVS/actions/runs/515334647
> v2: https://github.com/elibritstein/OVS/actions/runs/554986007
> v3: https://github.com/elibritstein/OVS/actions/runs/613226225
> v4: https://github.com/elibritstein/OVS/actions/runs/658415274
> v5: https://github.com/elibritstein/OVS/actions/runs/704357369
> v6: https://github.com/elibritstein/OVS/actions/runs/716304028
>
> [1] https://mails.dpdk.org/archives/dev/2020-October/187314.html
> [2] https://github.com/elibritstein/dpdk-stable/pull/1
>
>
> Eli Britstein (10):
>   netdev-offload: Add HW miss packet state recover API
>   netdev-dpdk: Introduce DPDK tunnel APIs
>   netdev-offload: Introduce an API to traverse ports
>   netdev-dpdk: Add flow_api support for netdev vxlan vports
>   netdev-offload-dpdk: Implement HW miss packet recover for vport
>   dpif-netdev: Add HW miss packet state recover logic
>   netdev-offload-dpdk: Change log rate limits
>   netdev-offload-dpdk: Support tunnel pop action
>   netdev-offload-dpdk: Support vports flows offload
>   netdev-dpdk-offload: Add vxlan pattern matching function
>
> Ilya Maximets (2):
>   netdev-offload: Allow offloading to netdev without ifindex.
>   netdev-offload: Disallow offloading to unrelated tunneling vports.
>
> Sriharsha Basavapatna (1):
>   dpif-netdev: Provide orig_in_port in metadata for tunneled packets
>
>  Documentation/howto/dpdk.rst  |   1 +
>  NEWS  |   2 +
>  lib/dpif-netdev.c |  97 +++--
>  lib/netdev-dpdk.c | 118 ++
>  lib/netdev-dpdk.h | 106 -
>  lib/netdev-offload-dpdk.c | 704 +++---
>  lib/netdev-offload-provider.h |   5 +
>  lib/netdev-offload-tc.c   |   8 +
>  lib/netdev-offload.c  |  47 ++-
>  lib/netdev-offload.h  |  10 +
>  lib/packets.h |   8 +-
>  11 files changed, 1022 insertions(+), 84 deletions(-)
>
> --
> 2.28.0.2311.g225365fb51
>
>

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or 

Re: [ovs-dev] [PATCH V6 00/13] Netdev vxlan-decap offload

[Eli Britstein]

On 4/6/2021 10:42 AM, Ivan Malov wrote:

External email: Use caution opening links or attachments


Hi Eli,

Thank you for improving the patch series gradually. May I clarify one
extra aspect (and I'm sorry if it has been discussed already): will OvS
always insert F1 first and then insert F2? I mean, yes, in the model, F2
should process packets coming from F1, but is it *technically* possible
for OvS to insert the rules in reverse order?


Usually the flows are created by the 
handle_packet_upcall->dp_netdev_flow_add.


handle_packet_upcall->dp_netdev_execute_actions is done first. 
Processing the packets is recursive (dp_netdev_recirculate), thus the 
flows are created in a LIFO manner, meaning F2 is first.


However, we cannot rely on such ordering. It is possible that F2 cannot 
be offloaded (unsupported action for example).


Also, in the future offloads will be inserted multi-threaded (see 
https://patchwork.ozlabs.org/project/openvswitch/list/?series=228959), 
so that's another reason we cannot rely on any ordering.




On 04/04/2021 12:54, Eli Britstein wrote:

VXLAN decap in OVS-DPDK configuration consists of two flows:
F1: in_port(ens1f0),eth(),ipv4(),udp(), actions:tnl_pop(vxlan_sys_4789)
F2: tunnel(),in_port(vxlan_sys_4789),eth(),ipv4(), actions:ens1f0_0

F1 is a classification flow. It has outer headers matches and it
classifies the packet as a VXLAN packet, and using tnl_pop action the
packet continues processing in F2.
F2 is a flow that has matches on tunnel metadata as well as on the inner
packet headers (as any other flow).

In order to fully offload VXLAN decap path, both F1 and F2 should be
offloaded. As there are more than one flow in HW, it is possible that
F1 is done by HW but F2 is not. Packet is received by SW, and should be
processed starting from F2 as F1 was already done by HW.
Rte_flows are applicable only on physical port IDs. Keeping the original
physical in port on which the packet is received on enables applying
vport flows (e.g. F2) on that physical port.

This patch-set makes use of [1] introduced in DPDK 20.11, that adds API
for tunnel offloads.

Note that MLX5 PMD has a bug that the tnl_pop private actions must be
first. In OVS it is not.
Fixing this issue is scheduled for 21.05 (and stable 20.11.2).
Meanwhile, tests were done with a workaround for it [2].

v2-v1:
- Tracking original in_port, and applying vport on that physical port 
instead of all PFs.

v3-v2:
- Traversing ports using a new API instead of flow_dump.
- Refactor packet state recover logic, with bug fix for error 
pop_header.

- One ref count for netdev in non-tunnel case.
- Rename variables, comments, rebase.
v4-v3:
- Extract orig_in_port from physdev for flow modify.
- Miss handling fixes.
v5-v4:
- Drop refactor offload rule creation commit.
- Comment about setting in_port in restore.
- Refactor vports flow offload commit.
v6-v5:
- Fixed duplicate netdev ref bug.

Travis:
v1: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftravis-ci.org%2Fgithub%2Felibritstein%2FOVS%2Fbuilds%2F756418552data=04%7C01%7Celibr%40nvidia.com%7C9604857ef03d4b4ee35508d8f8cf98a6%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637532917799220640%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=9lDdE7UXHSPFVHHQhp9OhPCB2eUdt2avc%2F3P39cYXfI%3Dreserved=0
v2: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftravis-ci.org%2Fgithub%2Felibritstein%2FOVS%2Fbuilds%2F758382963data=04%7C01%7Celibr%40nvidia.com%7C9604857ef03d4b4ee35508d8f8cf98a6%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637532917799230634%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=P9VJvydP8OWBe01zAy%2FhDrugktXlNO8xtX5enKux7mc%3Dreserved=0
v3: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftravis-ci.org%2Fgithub%2Felibritstein%2FOVS%2Fbuilds%2F761089087data=04%7C01%7Celibr%40nvidia.com%7C9604857ef03d4b4ee35508d8f8cf98a6%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637532917799230634%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=fhSFUtCle9BKnVRKlre3hjAjSuBaEjFvszA1WeDBHOc%3Dreserved=0
v4: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftravis-ci.org%2Fgithub%2Felibritstein%2FOVS%2Fbuilds%2F763146966data=04%7C01%7Celibr%40nvidia.com%7C9604857ef03d4b4ee35508d8f8cf98a6%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637532917799230634%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=xmGASTbUDxeFmNvntdLaYYiXJ%2Bil%2Bqkh1RuxAN3uTS8%3Dreserved=0
v5: 

Re: [ovs-dev] [PATCH V6 00/13] Netdev vxlan-decap offload

[Ivan Malov]

Hi Eli,

Thank you for improving the patch series gradually. May I clarify one 
extra aspect (and I'm sorry if it has been discussed already): will OvS 
always insert F1 first and then insert F2? I mean, yes, in the model, F2 
should process packets coming from F1, but is it *technically* possible 
for OvS to insert the rules in reverse order?


On 04/04/2021 12:54, Eli Britstein wrote:

VXLAN decap in OVS-DPDK configuration consists of two flows:
F1: in_port(ens1f0),eth(),ipv4(),udp(), actions:tnl_pop(vxlan_sys_4789)
F2: tunnel(),in_port(vxlan_sys_4789),eth(),ipv4(), actions:ens1f0_0

F1 is a classification flow. It has outer headers matches and it
classifies the packet as a VXLAN packet, and using tnl_pop action the
packet continues processing in F2.
F2 is a flow that has matches on tunnel metadata as well as on the inner
packet headers (as any other flow).

In order to fully offload VXLAN decap path, both F1 and F2 should be
offloaded. As there are more than one flow in HW, it is possible that
F1 is done by HW but F2 is not. Packet is received by SW, and should be
processed starting from F2 as F1 was already done by HW.
Rte_flows are applicable only on physical port IDs. Keeping the original
physical in port on which the packet is received on enables applying
vport flows (e.g. F2) on that physical port.

This patch-set makes use of [1] introduced in DPDK 20.11, that adds API
for tunnel offloads.

Note that MLX5 PMD has a bug that the tnl_pop private actions must be
first. In OVS it is not.
Fixing this issue is scheduled for 21.05 (and stable 20.11.2).
Meanwhile, tests were done with a workaround for it [2].

v2-v1:
- Tracking original in_port, and applying vport on that physical port instead 
of all PFs.
v3-v2:
- Traversing ports using a new API instead of flow_dump.
- Refactor packet state recover logic, with bug fix for error pop_header.
- One ref count for netdev in non-tunnel case.
- Rename variables, comments, rebase.
v4-v3:
- Extract orig_in_port from physdev for flow modify.
- Miss handling fixes.
v5-v4:
- Drop refactor offload rule creation commit.
- Comment about setting in_port in restore.
- Refactor vports flow offload commit.
v6-v5:
- Fixed duplicate netdev ref bug.

Travis:
v1: https://travis-ci.org/github/elibritstein/OVS/builds/756418552
v2: https://travis-ci.org/github/elibritstein/OVS/builds/758382963
v3: https://travis-ci.org/github/elibritstein/OVS/builds/761089087
v4: https://travis-ci.org/github/elibritstein/OVS/builds/763146966
v5: https://travis-ci.org/github/elibritstein/OVS/builds/765271879
v6: https://travis-ci.org/github/elibritstein/OVS/builds/765816800

GitHub Actions:
v1: https://github.com/elibritstein/OVS/actions/runs/515334647
v2: https://github.com/elibritstein/OVS/actions/runs/554986007
v3: https://github.com/elibritstein/OVS/actions/runs/613226225
v4: https://github.com/elibritstein/OVS/actions/runs/658415274
v5: https://github.com/elibritstein/OVS/actions/runs/704357369
v6: https://github.com/elibritstein/OVS/actions/runs/716304028

[1] https://mails.dpdk.org/archives/dev/2020-October/187314.html
[2] https://github.com/elibritstein/dpdk-stable/pull/1


Eli Britstein (10):
   netdev-offload: Add HW miss packet state recover API
   netdev-dpdk: Introduce DPDK tunnel APIs
   netdev-offload: Introduce an API to traverse ports
   netdev-dpdk: Add flow_api support for netdev vxlan vports
   netdev-offload-dpdk: Implement HW miss packet recover for vport
   dpif-netdev: Add HW miss packet state recover logic
   netdev-offload-dpdk: Change log rate limits
   netdev-offload-dpdk: Support tunnel pop action
   netdev-offload-dpdk: Support vports flows offload
   netdev-dpdk-offload: Add vxlan pattern matching function

Ilya Maximets (2):
   netdev-offload: Allow offloading to netdev without ifindex.
   netdev-offload: Disallow offloading to unrelated tunneling vports.

Sriharsha Basavapatna (1):
   dpif-netdev: Provide orig_in_port in metadata for tunneled packets

  Documentation/howto/dpdk.rst  |   1 +
  NEWS  |   2 +
  lib/dpif-netdev.c |  97 +++--
  lib/netdev-dpdk.c | 118 ++
  lib/netdev-dpdk.h | 106 -
  lib/netdev-offload-dpdk.c | 704 +++---
  lib/netdev-offload-provider.h |   5 +
  lib/netdev-offload-tc.c   |   8 +
  lib/netdev-offload.c  |  47 ++-
  lib/netdev-offload.h  |  10 +
  lib/packets.h |   8 +-
  11 files changed, 1022 insertions(+), 84 deletions(-)



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