On Fri, Feb 4, 2022 at 9:43 PM Gaetan Rivet wrote:
> Port flush and offload uninit should be moved after the datapath
> has been reconfigured. That way, no other thread such as PMDs will
> find this port to poll and enqueue further offload requests.
>
> After a flush, almost no further offload
>>> On 2/1/22 12:38, Gaëtan Rivet wrote:
> >>>>> On Mon, Jan 31, 2022, at 20:33, Ilya Maximets wrote:
> >>>>>> On 1/31/22 11:42, Gaëtan Rivet wrote:
> >>>>>>> On Thu, Jan 27, 2022, at 11:38, Ilya Maximets wrote:
> >>>>&
On Thu, Jan 27, 2022 at 4:08 PM Ilya Maximets wrote:
>
> On 1/27/22 07:42, Sriharsha Basavapatna via dev wrote:
> > In dp_netdev_pmd_remove_flow() we schedule the deletion of an
> > offloaded flow, if a mark has been assigned to the flow. But if
> > this occurs in the win
On Thu, Jan 27, 2022 at 2:45 PM Gaëtan Rivet wrote:
>
> On Thu, Jan 27, 2022, at 07:42, Sriharsha Basavapatna via dev wrote:
> > In dp_netdev_pmd_remove_flow() we schedule the deletion of an
> > offloaded flow, if a mark has been assigned to the flow. But if
> > this occur
In dp_netdev_pmd_remove_flow() we schedule the deletion of an
offloaded flow, if a mark has been assigned to the flow. But if
this occurs in the window in which the offload thread completes
offloading the flow and assigns a mark to the flow, then we miss
deleting the flow. This problem has been
On Wed, Jan 26, 2022 at 3:26 AM Ilya Maximets wrote:
>
> On 1/23/22 17:28, Sriharsha Basavapatna wrote:
> > Hi Ilya,
> >
> > On Wed, Jan 19, 2022 at 7:24 AM Ilya Maximets wrote:
> >
> >>
> >> I also spotted one bug where the flow stays offloaded if it gets added
> >> and removed shortly after
Hi Ilya,
On Wed, Jan 19, 2022 at 7:24 AM Ilya Maximets wrote:
>
> On 9/15/21 15:45, Maxime Coquelin wrote:
> > Hi,
> >
> > On 9/8/21 11:47 AM, Gaetan Rivet wrote:
> >> This patch series aims to improve the performance of the management
> >> of hw-offloads in dpif-netdev. In the current version,
On Tue, Nov 2, 2021 at 1:48 AM Ilya Maximets wrote:
>
> On 10/30/21 09:04, Sriharsha Basavapatna wrote:
> > On Mon, Aug 9, 2021 at 6:28 PM Ilya Maximets wrote:
> >>
> >> There are cases where users might want simple forwarding or drop rules
> >> for all packets received from a specific port, e.g
The hw_miss_packet_recover() API results in performance degradation, for
ports that are either not offload capable or do not support this specific
offload API.
For example, in the test configuration shown below, the vhost-user port
does not support offloads and the VF port doesn't support hw_miss
Hi Eli,
On Sun, Nov 21, 2021 at 12:03 PM Eli Britstein via dev
wrote:
>
> Hi Harsha,
>
> It's a clever idea, though have some problems in the implementation. PSB.
Thanks, please see my response below.
>
>
> On 11/20/2021 11:20 AM, Sriharsha Basavapatna wrote:
> > The hw_miss_packet_recover()
The hw_miss_packet_recover() API results in performance degradation, for
ports that are either not offload capable or do not support this specific
offload API.
For example, in the test configuration shown below, the vhost-user port
does not support offloads and the VF port doesn't support hw_miss
On Thu, Nov 11, 2021 at 3:22 PM Sriharsha Basavapatna
wrote:
>
> Hi Ilya,
>
> On Wed, Nov 10, 2021 at 11:31 PM Ilya Maximets wrote:
> >
> > Hi, Harsha.
> >
> > I was thinking about 3x performance drop due to enabling
> > of experimental API that you reported during the meeting
> > today. I just
Hi Ilya,
On Wed, Nov 10, 2021 at 11:31 PM Ilya Maximets wrote:
>
> Hi, Harsha.
>
> I was thinking about 3x performance drop due to enabling
> of experimental API that you reported during the meeting
> today. I just want to clarify one thing to be sure that
> you're not making the same mistake
On Mon, Aug 9, 2021 at 6:28 PM Ilya Maximets wrote:
>
> There are cases where users might want simple forwarding or drop rules
> for all packets received from a specific port, e.g ::
>
> "in_port=1,actions=2"
> "in_port=2,actions=IN_PORT"
> "in_port=3,vlan_tci=0x1234/0x1fff,actions=drop"
>
On Fri, Aug 13, 2021 at 6:27 PM Gaëtan Rivet wrote:
> On Fri, Aug 13, 2021, at 08:14, Sriharsha Basavapatna via dev wrote:
> > The 's_tnl' member in flow_patterns and flow_actions should be
> > to set to DS_EMPTY_INITIALIZER, to be consistent with dynamic string
> > initiali
The 's_tnl' member in flow_patterns and flow_actions should be
to set to DS_EMPTY_INITIALIZER, to be consistent with dynamic string
initializations.
Also, there's a potential memory leak of flow_patterns->s_tnl.
Fix this by destroying s_tnl in free_flow_patterns().
Fixes: 507d20e77bfe
On Fri, Aug 13, 2021 at 4:07 AM Ilya Maximets wrote:
>
> On 8/12/21 8:33 AM, Sriharsha Basavapatna via dev wrote:
> > In netdev_offload_dpdk_flow_create() when an offload request fails,
> > dump_flow() is called to log a warning message. The 's_tnl' string
> > in flow_p
In netdev_offload_dpdk_flow_create() when an offload request fails,
dump_flow() is called to log a warning message. The 's_tnl' string
in flow_patterns gets initialized in vport_to_rte_tunnel() conditionally
via ds_put_format(). If it is not initialized, it crashes later in
On Wed, Aug 11, 2021 at 4:55 PM Ilya Maximets wrote:
>
> On 8/11/21 7:05 AM, Sriharsha Basavapatna via dev wrote:
> > On Wed, Aug 11, 2021 at 6:21 AM Gaëtan Rivet wrote:
> >>
> >> On Wed, Aug 4, 2021, at 14:37, Sriharsha Basavapatna via dev wrote:
> >>>
On Wed, Aug 11, 2021 at 6:21 AM Gaëtan Rivet wrote:
>
> On Wed, Aug 4, 2021, at 14:37, Sriharsha Basavapatna via dev wrote:
> > In netdev_offload_dpdk_flow_create() when an offload request fails,
> > dump_flow() is called to log a warning message. The 's_tnl' string
> &g
On Wed, Aug 4, 2021 at 6:07 PM Sriharsha Basavapatna
wrote:
>
> In netdev_offload_dpdk_flow_create() when an offload request fails,
> dump_flow() is called to log a warning message. The 's_tnl' string
> in flow_patterns gets initialized in vport_to_rte_tunnel() conditionally
> via
In netdev_offload_dpdk_flow_create() when an offload request fails,
dump_flow() is called to log a warning message. The 's_tnl' string
in flow_patterns gets initialized in vport_to_rte_tunnel() conditionally
via ds_put_format(). If it is not initialized, it crashes later in
On Thu, Jun 24, 2021 at 12:23 AM Ilya Maximets wrote:
>
> On 6/23/21 5:52 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(),
Gaetan,
Thanks for sending out this list.
Here's the list that Broadcom is reviewing/working on for the v2.16 release:
OVS-DPDK:
1) VXLAN decap offload: v6:
https://patchwork.ozlabs.org/project/openvswitch/list/?series=237293
-- Completed review; acked v6 patchset.
2) Port-forward (direct
From: Ilya Maximets
There are some cases where users want to have simple forwarding or drop
rules for all packets received from particular port, i.e :
"in_port=1,actions=2"
"in_port=1,actions=IN_PORT"
"in_port=1,actions=drop"
There are also cases where complex OF flows could be
On Tue, Apr 27, 2021 at 6:42 PM Eli Britstein wrote:
>
>
> On 4/27/2021 2:45 PM, Sriharsha Basavapatna wrote:
> > On Tue, Apr 27, 2021 at 4:26 PM Ilya Maximets wrote:
> >> On 4/27/21 11:56 AM, Sriharsha Basavapatna via dev wrote:
> >>> Hi Eli,
> >&g
On Tue, Apr 27, 2021 at 4:26 PM Ilya Maximets wrote:
>
> On 4/27/21 11:56 AM, Sriharsha Basavapatna via dev wrote:
> > Hi Eli,
> >
> > On Sun, Apr 25, 2021 at 6:22 PM Eli Britstein wrote:
> >>
> >> Hi Harsha,
> >>
> >> On 4/20/2021 1
Hi Eli,
On Sun, Apr 25, 2021 at 6:22 PM Eli Britstein wrote:
>
> Hi Harsha,
>
> On 4/20/2021 11:07 AM, Sriharsha Basavapatna wrote:
> > Sometimes a port might be configured with a single flow that just
> > forwards packets to another port. This would be useful in configs
> > where the bridge is
Sometimes a port might be configured with a single flow that just
forwards packets to another port. This would be useful in configs
where the bridge is just fowarding packets between two ports (for
example, between a vhost-user port and a physical port). A flow
that matches only on the in_port and
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(),
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
On Thu, Mar 25, 2021 at 2:40 PM Eli Britstein wrote:
>
> Hello,
>
> 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.
>
> See
On Wed, Mar 17, 2021 at 12:05 PM Eli Britstein wrote:
>
> Vports are virtual, OVS only logical devices, so rte_flows cannot be
> applied as is on them. Instead, apply the rules the physical port from
> which the packet has arrived, provided by orig_in_port field.
>
> Signed-off-by: Eli Britstein
On Wed, Mar 17, 2021 at 12:05 PM Eli Britstein wrote:
>
> A miss in virtual port offloads means the flow with tnl_pop was
> offloaded, but not the following one. Recover the state and continue
> with SW processing.
>
> Signed-off-by: Eli Britstein
> Reviewed-by: Gaetan Rivet
> ---
>
On Mon, Mar 15, 2021 at 3:57 PM Eli Britstein wrote:
>
>
> On 3/15/2021 11:04 AM, Sriharsha Basavapatna wrote:
> > On Tue, Mar 2, 2021 at 4:56 PM Eli Britstein wrote:
> >> From: Sriharsha Basavapatna
> >>
> >> When an encapsulated packet is recirculated through a TUNNEL_POP
> >> action, the
On Tue, Mar 2, 2021 at 4:56 PM Eli Britstein wrote:
>
> From: Sriharsha Basavapatna
>
> When an encapsulated packet is recirculated through a TUNNEL_POP
> action, the metadata gets reinitialized and the originating physical
> port information is lost. When this flow gets processed by the vport
>
On Thu, Feb 25, 2021 at 7:51 PM Eli Britstein wrote:
>
>
> On 2/25/2021 9:35 AM, Sriharsha Basavapatna wrote:
> > On Wed, Feb 24, 2021 at 4:50 PM Eli Britstein wrote:
> >>
> >> On 2/24/2021 12:37 PM, Sriharsha Basavapatna wrote:
> >>> On Wed, Feb 10, 2021 at 8:57 PM Eli Britstein wrote:
>
On Thu, Feb 25, 2021 at 7:50 PM Eli Britstein wrote:
>
>
> On 2/25/2021 9:35 AM, Sriharsha Basavapatna wrote:
> > On Wed, Feb 24, 2021 at 1:50 PM Eli Britstein wrote:
> >>
> >> On 2/24/2021 9:52 AM, Sriharsha Basavapatna wrote:
> >>> On Wed, Feb 10, 2021 at 8:57 PM Eli Britstein wrote:
>
On Thu, Feb 25, 2021 at 7:51 PM Eli Britstein wrote:
>
>
> On 2/25/2021 9:35 AM, Sriharsha Basavapatna wrote:
> > On Wed, Feb 24, 2021 at 3:47 PM Eli Britstein wrote:
> >>
> >> On 2/24/2021 11:55 AM, Sriharsha Basavapatna wrote:
> >>> On Wed, Feb 10, 2021 at 8:57 PM Eli Britstein wrote:
>
On Thu, Feb 25, 2021 at 7:50 PM Eli Britstein wrote:
>
>
> On 2/25/2021 9:34 AM, Sriharsha Basavapatna wrote:
> > On Tue, Feb 23, 2021 at 7:24 PM Eli Britstein wrote:
> >>
> >> On 2/23/2021 3:10 PM, Sriharsha Basavapatna wrote:
> >>> On Wed, Feb 10, 2021 at 8:57 PM Eli Britstein wrote:
> A
On Wed, Feb 24, 2021 at 4:50 PM Eli Britstein wrote:
>
>
> On 2/24/2021 12:37 PM, Sriharsha Basavapatna wrote:
> > On Wed, Feb 10, 2021 at 8:57 PM Eli Britstein wrote:
> >> Vports are virtual, OVS only logical devices, so rte_flows cannot be
> >> applied as is on them. Instead, apply the rules
On Wed, Feb 24, 2021 at 3:47 PM Eli Britstein wrote:
>
>
> On 2/24/2021 11:55 AM, Sriharsha Basavapatna wrote:
> > On Wed, Feb 10, 2021 at 8:57 PM Eli Britstein wrote:
> >> Refactor offload rule creation as a pre-step towards tunnel matching
> >> that depend on the netdev.
> >>
> >>
On Wed, Feb 24, 2021 at 1:50 PM Eli Britstein wrote:
>
>
> On 2/24/2021 9:52 AM, Sriharsha Basavapatna wrote:
> > On Wed, Feb 10, 2021 at 8:57 PM Eli Britstein wrote:
> >> Support tunnel pop action.
> >>
> >> Signed-off-by: Eli Britstein
> >> Reviewed-by: Gaetan Rivet
> >> ---
> >>
On Tue, Feb 23, 2021 at 7:24 PM Eli Britstein wrote:
>
>
> On 2/23/2021 3:10 PM, Sriharsha Basavapatna wrote:
> > On Wed, Feb 10, 2021 at 8:57 PM Eli Britstein wrote:
> >> A miss in virtual port offloads means the flow with tnl_pop was
> >> offloaded, but not the following one. Recover the state
On Tue, Feb 23, 2021 at 6:55 PM Eli Britstein wrote:
>
>
> On 2/23/2021 3:10 PM, Sriharsha Basavapatna wrote:
>
> On Wed, Feb 10, 2021 at 8:57 PM Eli Britstein wrote:
>
> When offloading vports, we don't configure rte_flow on the vport itself,
> as it is not a physical dpdk port, but rather on
On Tue, Feb 23, 2021 at 6:51 PM Eli Britstein wrote:
>
>
> On 2/23/2021 3:10 PM, Sriharsha Basavapatna wrote:
>
> On Wed, Feb 10, 2021 at 8:57 PM Eli Britstein wrote:
>
> When the HW offload involves multiple flows, like in tunnel decap path,
> it is possible that not all flows in the path are
On Wed, Feb 10, 2021 at 8:57 PM Eli Britstein wrote:
>
> Vports are virtual, OVS only logical devices, so rte_flows cannot be
> applied as is on them. Instead, apply the rules the physical port from
> which the packet has arrived, provided by orig_in_port field.
>
> Signed-off-by: Eli Britstein
On Wed, Feb 10, 2021 at 8:57 PM Eli Britstein wrote:
>
> Refactor offload rule creation as a pre-step towards tunnel matching
> that depend on the netdev.
>
> Signed-off-by: Eli Britstein
> Reviewed-by: Gaetan Rivet
> ---
> lib/netdev-offload-dpdk.c | 106 --
On Wed, Feb 10, 2021 at 8:57 PM Eli Britstein wrote:
>
> Support tunnel pop action.
>
> Signed-off-by: Eli Britstein
> Reviewed-by: Gaetan Rivet
> ---
> Documentation/howto/dpdk.rst | 1 +
> NEWS | 1 +
> lib/netdev-offload-dpdk.c| 173
On Wed, Feb 10, 2021 at 8:57 PM Eli Britstein wrote:
>
> Recover the packet if it was partially processed by the HW. Fallback to
> lookup flow by mark association.
>
> Signed-off-by: Eli Britstein
> Reviewed-by: Gaetan Rivet
> ---
> lib/dpif-netdev.c | 46
On Tue, Feb 23, 2021 at 5:14 PM Eli Britstein wrote:
>
>
> On 2/23/2021 12:48 PM, Sriharsha Basavapatna wrote:
> > On Sun, Feb 21, 2021 at 7:04 PM Eli Britstein wrote:
> >>
> >> On 2/18/2021 6:38 PM, Kovacevic, Marko wrote:
> >>> External email: Use caution opening links or attachments
> >>>
>
On Wed, Feb 10, 2021 at 8:57 PM Eli Britstein wrote:
>
> A miss in virtual port offloads means the flow with tnl_pop was
> offloaded, but not the following one. Recover the state and continue
> with SW processing.
Relates to my comment on Patch-1; please explain what is meant by
recovering the
On Wed, Feb 10, 2021 at 8:57 PM Eli Britstein wrote:
>
> When offloading vports, we don't configure rte_flow on the vport itself,
> as it is not a physical dpdk port, but rather on uplinks. Implement
> those APIs as a pre-step to enable iterate over the ports.
We don't need these flow_dump APIs,
On Wed, Feb 10, 2021 at 8:57 PM Eli Britstein wrote:
>
> When the HW offload involves multiple flows, like in tunnel decap path,
> it is possible that not all flows in the path are offloaded, resulting
> in partial processing in HW. In order to proceed with rest of the
> processing in SW, the
On Sun, Feb 21, 2021 at 7:04 PM Eli Britstein wrote:
>
>
> On 2/18/2021 6:38 PM, Kovacevic, Marko wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > <...>
> >> Sending to Marko. As he wasn't subscribed to ovs-dev then.
> >>
> > <...>
> >>> VXLAN decap in OVS-DPDK
On Tue, Feb 9, 2021 at 8:41 PM Eli Britstein wrote:
>
>
> On 2/8/2021 6:21 PM, Sriharsha Basavapatna wrote:
> > On Mon, Feb 8, 2021 at 7:33 PM Eli Britstein wrote:
> >>
> >> On 2/8/2021 3:11 PM, Sriharsha Basavapatna wrote:
> >>> On Sun, Feb 7, 2021 at 4:58 PM Eli Britstein wrote:
> On
On Mon, Feb 8, 2021 at 7:33 PM Eli Britstein wrote:
>
>
> On 2/8/2021 3:11 PM, Sriharsha Basavapatna wrote:
> > On Sun, Feb 7, 2021 at 4:58 PM Eli Britstein wrote:
> >>
> >> On 2/5/2021 8:26 PM, Sriharsha Basavapatna wrote:
> >>> On Fri, Feb 5, 2021 at 4:55 PM Sriharsha Basavapatna
> >>> wrote:
On Sun, Feb 7, 2021 at 4:58 PM Eli Britstein wrote:
>
>
> On 2/5/2021 8:26 PM, Sriharsha Basavapatna wrote:
> > On Fri, Feb 5, 2021 at 4:55 PM Sriharsha Basavapatna
> > wrote:
> >> On Wed, Jan 27, 2021 at 11:40 PM Eli Britstein wrote:
> >>> VXLAN decap in OVS-DPDK configuration consists of two
On Fri, Feb 5, 2021 at 4:55 PM Sriharsha Basavapatna
wrote:
>
> On Wed, Jan 27, 2021 at 11:40 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:
When an encapsulated packet is recirculated through a TUNNEL_POP
action, the metadata gets reinitialized and the originating physical
port information is lost. When this flow gets processed by the vport
and it needs to be offloaded, we can't figure out the physical port
through which the tunneled
On Wed, Jan 27, 2021 at 11:40 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.
On Sun, Jan 10, 2021 at 12:25 PM Eli Britstein wrote:
>
>
> On 1/7/2021 9:10 PM, Sriharsha Basavapatna wrote:
> > Hi Eli,
> >
> > On Mon, Dec 28, 2020 at 11:43 PM Eli Britstein wrote:
> >> Netdev datapath offloads are done in a separate thread, using messaging
> >> between the threads. With port
Hi Eli,
On Mon, Dec 28, 2020 at 11:43 PM Eli Britstein wrote:
>
> Netdev datapath offloads are done in a separate thread, using messaging
> between the threads. With port removal there is a race between the offload
> thread removing the offloaded rules and the actual port removal, so some
>
On Tue, Oct 20, 2020 at 8:59 PM Ilya Maximets wrote:
>
> On 10/20/20 5:04 PM, Eli Britstein wrote:
> >
> > On 10/20/2020 1:12 PM, Sriharsha Basavapatna wrote:
> >> On Tue, Oct 20, 2020 at 2:40 PM Ilya Maximets wrote:
> >>> On 10/20/20 10:51 AM, Sriharsha Basavapatna wrote:
> On Mon, Oct 19,
The offload layer clears the L4 protocol mask in the L3 item, when the
L4 item is passed for matching, as an optimization. This can be confusing
while parsing the headers in the PMD. Also, the datapath flow specifies
this field to be matched. This optimization is best left to the PMD.
This patch
On Fri, Jul 10, 2020 at 5:37 PM Sriharsha Basavapatna
wrote:
>
> Hi,
>
> This patchset fixes some issues found during netdev-offload-dpdk testing.
>
> Patch-1: Initialize rte 'transfer' attribute for mark/rss offload.
Patch-1 is not needed (discussed in an earlier thread).
> Patch-2: Pass L4
On Tue, Oct 20, 2020 at 2:40 PM Ilya Maximets wrote:
>
> On 10/20/20 10:51 AM, Sriharsha Basavapatna wrote:
> > On Mon, Oct 19, 2020 at 7:59 PM Ilya Maximets wrote:
> >>
> >> On 10/18/20 9:10 AM, Eli Britstein wrote:
> >>> Struct match has the tunnel values/masks in
> >>>
On Mon, Oct 19, 2020 at 7:59 PM Ilya Maximets wrote:
>
> On 10/18/20 9:10 AM, Eli Britstein wrote:
> > Struct match has the tunnel values/masks in
> > match->flow.tunnel/match->wc.masks.tunnel.
> > Load actions such as load:0xa566c10->NXM_NX_TUN_IPV4_DST[],
> > load:0xbba->NXM_NX_TUN_ID[] are
On Mon, Oct 19, 2020 at 7:59 PM Ilya Maximets wrote:
>
> On 10/18/20 9:10 AM, Eli Britstein wrote:
> > Struct match has the tunnel values/masks in
> > match->flow.tunnel/match->wc.masks.tunnel.
> > Load actions such as load:0xa566c10->NXM_NX_TUN_IPV4_DST[],
> > load:0xbba->NXM_NX_TUN_ID[] are
On Wed, Oct 14, 2020 at 8:29 PM Mark Gray wrote:
>
> This seems to break tests for me? Did you run a "make check"? I didn't
> apply the whole series because patch 2 doesn't apply so maybe that is
> needed for the tests to pass.
I rebased patch-2 and it now applies fine. But I'm seeing errors
On Mon, Oct 12, 2020 at 7:57 PM Eli Britstein wrote:
>
> In case of a flow modification, preserve the HW statistics of the old HW
> flow to the new one.
>
> Fixes: 3c7330ebf036 ("netdev-offload-dpdk: Support offload of output action.")
> Signed-off-by: Eli Britstein
> Reviewed-by: Gaetan Rivet
On Mon, Oct 12, 2020 at 4:43 PM Eli Britstein wrote:
>
>
> On 10/12/2020 11:45 AM, Sriharsha Basavapatna wrote:
> > On Sun, Sep 6, 2020 at 5:52 PM Eli Britstein wrote:
> >> ping
> >>
> >> On 7/30/2020 4:52 PM, Eli Britstein wrote:
> >>> In case of a flow modification, preserve the HW statistics
On Mon, Oct 12, 2020 at 4:48 PM Eli Britstein wrote:
>
>
> On 10/12/2020 10:20 AM, Sriharsha Basavapatna wrote:
> > On Sun, Sep 6, 2020 at 5:51 PM Eli Britstein wrote:
> >> ping
> >>
> >> On 7/30/2020 1:58 PM, Eli Britstein wrote:
> >>> From: Lei Wang
> >>>
> >>> Struct match has the tunnel
On Sun, Sep 6, 2020 at 5:52 PM Eli Britstein wrote:
>
> ping
>
> On 7/30/2020 4:52 PM, Eli Britstein wrote:
> > In case of a flow modification, preserve the HW statistics of the old HW
> > flow to the new one.
> >
> > Signed-off-by: Eli Britstein
> > Reviewed-by: Gaetan Rivet
Update fixes: tag
On Sun, Sep 6, 2020 at 5:51 PM Eli Britstein wrote:
>
> ping
>
> On 7/30/2020 1:58 PM, Eli Britstein wrote:
> > From: Lei Wang
> >
> > Struct match has the tunnel values/masks in
> > match->flow.tunnel/match->wc.masks.tunnel.
> > Load actions such as load:0xa566c10->NXM_NX_TUN_IPV4_DST[],
> >
On Thu, Jul 16, 2020 at 2:52 PM Ilya Maximets wrote:
>
> On 7/16/20 10:01 AM, Eli Britstein wrote:
> >
> > On 7/16/2020 1:37 AM, Ilya Maximets wrote:
> >> On 7/15/20 8:30 PM, Stokes, Ian wrote:
> On 15/07/2020 17:00, Ilya Maximets wrote:
> > Main thread will try to pause/stop all
On Mon, Jul 13, 2020 at 1:28 PM Eli Britstein wrote:
>
>
> On 7/13/2020 10:55 AM, Sriharsha Basavapatna wrote:
> > On Mon, Jul 13, 2020 at 1:07 PM Eli Britstein wrote:
> >>
> >> On 7/10/2020 3:07 PM, Sriharsha Basavapatna wrote:
> >>> The offload layer doesn't initialize the 'transfer' attribute
On Mon, Jul 13, 2020 at 1:07 PM Eli Britstein wrote:
>
>
> On 7/10/2020 3:07 PM, Sriharsha Basavapatna wrote:
> > The offload layer doesn't initialize the 'transfer' attribute
> > for mark/rss offload (partial offload). It should be set to 0.
> >
> > Fixes: 60e778c7533a ("netdev-offload-dpdk:
This patch refactors dp_netdev_flow_offload_put() to prepare for
changes to support partial action offload, in subsequent patches.
- Move mark allocation code into a separate wrapper function, outside of
dp_netdev_flow_offload_put() to improve readability and to facilitate
more changes in
Hi,
This patchset extends the "Partial HW acceleration" mode to offload a
part of the action processing to HW, instead of offloading just lookup
(MARK/RSS), for "vhost-user" ports. This is referred to as "Partial Action
Offload". This mode does not require SRIOV/switchdev configuration. In this
If the output-port is a vhost-user port and the action is POP_VLAN,
offload the action on the ingress device if it is offload capable.
Note:
- With ingress partial action offload, the flow must be added to the
mark-to-flow table. Otherwise, since the action (e.g, POP_VLAN) is
already
To identify flows that have actions partially offloaded, the dp and
offloaded fields in the output of dpctl/flow-dump, are updated with
the values: "dp:ovs,dpdk" and "offloaded:partial-action".
Signed-off-by: Sriharsha Basavapatna
---
lib/dpctl.c | 5 -
In this patch, we support offloading of VXLAN_ENCAP action for a vhost-user
port (aka "partial-action-offload"). At the time of offloading the flow, we
determine if the flow can be offloaded to an egress device, if the input
port is not offload capable such as a vhost-user port. We then offload
Hi Ilya,
Thanks for your comments, please see my response inline.
On Fri, Jul 10, 2020 at 5:41 PM Ilya Maximets wrote:
>
> On 7/9/20 8:47 AM, Sriharsha Basavapatna via dev wrote:
> > Hi,
> >
> > This patchset extends the "Partial HW acceleration" mode t
This patch adds a function to determine if a given netdev belongs to the
dpdk-vhost class, using the netdev_class specific data.
Reviewed-by: Hemal Shah
Signed-off-by: Sriharsha Basavapatna
---
lib/netdev-dpdk.c | 5 +
lib/netdev-dpdk.h | 1 +
2 files changed, 6 insertions(+)
diff --git
In this patch we check if action processing (apart from OUTPUT action),
should be skipped for a given dp_netdev_flow. Specifically, we check if
the action is TNL_PUSH and if it has been offloaded to HW, then we do not
push the tunnel header in SW. The datapath only executes the OUTPUT action.
The
If the input-port is a vhost-user port and the action is PUSH_VLAN,
offload the action on the egress device if it is offload capable.
Signed-off-by: Sriharsha Basavapatna
---
lib/dpif-netdev.c | 32 ++--
lib/dpif.c| 2 +-
For flows that offload partial actions in egress direction,
provide the right netdev to fetch statistics.
Reviewed-by: Hemal Shah
Signed-off-by: Sriharsha Basavapatna
---
lib/dpif-netdev.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/lib/dpif-netdev.c
The offload layer doesn't initialize the 'transfer' attribute
for mark/rss offload (partial offload). It should be set to 0.
Fixes: 60e778c7533a ("netdev-offload-dpdk: Framework for actions offload.")
Signed-off-by: Sriharsha Basavapatna
---
lib/netdev-offload-dpdk.c | 3 ++-
1 file changed, 2
IP_ECN_MASK is set unconditionally in the mask field for a
tunneled flow. Set this only when the ECN field is matched.
Fixes: abcd4402fec4 ("tunnel: Only un-wildcard the ECN bits for IP traffic")
Signed-off-by: Sriharsha Basavapatna
---
ofproto/tunnel.c | 8 ++--
1 file changed, 6
The offload layer clears the L4 protocol mask in the L3 item, when the
L4 item is passed for matching, as an optimization. This can be confusing
while parsing the headers in the PMD. Also, the datapath flow specifies
this field to be matched. This optimization is best left to the PMD.
This patch
Hi,
This patchset fixes some issues found during netdev-offload-dpdk testing.
Patch-1: Initialize rte 'transfer' attribute for mark/rss offload.
Patch-2: Pass L4 protocol-id to match in the rte_flow_item.
Patch-3: Set IP_ECN_MASK only when the ECN field is matched.
Thanks,
-Harsha
**
v1:
On Fri, Jul 10, 2020 at 4:01 PM Sriharsha Basavapatna <
sriharsha.basavapa...@broadcom.com> wrote:
>
>
> On Sun, Jul 5, 2020 at 6:00 PM Eli Britstein wrote:
>
>>
>> On 7/5/2020 2:48 PM, Sriharsha Basavapatna wrote:
>> > The offload layer clears the L4 protocol mask in the L3 item, when the
>> >
Please ignore this patch, I'm resending it in a patchset.
Thanks,
-Harsha
On Mon, Jul 6, 2020 at 6:54 PM Sriharsha Basavapatna <
sriharsha.basavapa...@broadcom.com> wrote:
> A gentle reminder on this patch.
> Thanks,
> -Harsha
>
> On Mon, Jun 29, 2020 at 11:31 PM Sriharsha Basavapatna
> wrote:
On Sun, Jul 5, 2020 at 6:00 PM Eli Britstein wrote:
>
> On 7/5/2020 2:48 PM, Sriharsha Basavapatna wrote:
> > The offload layer clears the L4 protocol mask in the L3 item, when the
> > L4 item is passed for matching, as an optimization. This can be confusing
> > while parsing the headers in the
Hi Ilya,
I removed the RFC tag on this partial-offload patchset and it is
rebased to the latest master branch. We are targeting this for 2.14.
So just a gentle reminder on this offload patchset.
Thanks,
-Harsha
On Thu, Jul 9, 2020 at 12:17 PM Sriharsha Basavapatna
wrote:
>
> Hi,
>
> This
In this patch, we support offloading of VXLAN_ENCAP action for a vhost-user
port (aka "partial-action-offload"). At the time of offloading the flow, we
determine if the flow can be offloaded to an egress device, if the input
port is not offload capable such as a vhost-user port. We then offload
If the input-port is a vhost-user port and the action is PUSH_VLAN,
offload the action on the egress device if it is offload capable.
Signed-off-by: Sriharsha Basavapatna
---
lib/dpif-netdev.c | 59 ---
lib/odp-execute.c | 11 +
2 files
If the output-port is a vhost-user port and the action is POP_VLAN,
offload the action on the ingress device if it is offload capable.
Note:
- With ingress partial action offload, the flow must be added to the
mark-to-flow table. Otherwise, since the action (e.g, POP_VLAN) is
already
This patch adds a function to determine if a given netdev belongs to the
dpdk-vhost class, using the netdev_class specific data.
Reviewed-by: Hemal Shah
Signed-off-by: Sriharsha Basavapatna
---
lib/netdev-dpdk.c | 5 +
lib/netdev-dpdk.h | 1 +
2 files changed, 6 insertions(+)
diff --git
1 - 100 of 239 matches
Mail list logo
