On 7/20/22 14:18, Ivan Malov wrote:
> DPDK has got support for offloads involving assignment of per-packet
> Rx metadata (flag, mark, tunnel ID and the likes). However, delivery
> of such metadata from the NIC to the PMD might need to be negotiated
> in advance. API [1] addresses that problem. Make OvS invoke this API.
> 
> Another problem is how flow rules with attribute "transfer" refer to
> embedded switch ports by means of their representors. Action PORT_ID
> has proved ambiguous: it refers to a DPDK ethdev, but in fact steers
> packets to the entity represented by the ethdev, in example, to a VF.
> The problem is addressed by [2]. Use the solution in OvS accordingly.
> 
> In addition, [2] and [3] address filtering traffic by input ports of
> the embedded switch. In the suggested approach, "transfer" rules are
> managed via the only ethdev with sufficient privileges, whilst match
> criteria include an explicit item to indicate the desired input port.
> Revisit OvS support for "transfer" rules to follow the said approach.
> 
> The following tests have been considered so far:
> - build check with the current dpdk-next-net;
> - running "make check" for every patch;
> - tunnel offload demo with net/sfc PMD.
> 
> [1] http://mails.dpdk.org/archives/dev/2021-October/224291.html
> [2] http://mails.dpdk.org/archives/dev/2021-October/224620.html
> [3] http://mails.dpdk.org/archives/dev/2021-October/225081.html
> ---
>  v1 -> v2: amendments to care about proxy detach and port ID logging
>  v2 -> v3: a minor adjustment in the cover letter's subject line
> 
> Ivan Malov (3):
>   netdev-dpdk: negotiate delivery of per-packet Rx metadata
>   netdev-offload-dpdk: replace action PORT_ID with REPRESENTED_PORT
>   netdev-offload-dpdk: use flow transfer proxy mechanism
> 
>  lib/netdev-dpdk.c         | 141 +++++++++++++++++++++++++++++++++-----
>  lib/netdev-dpdk.h         |   4 +-
>  lib/netdev-offload-dpdk.c |  91 +++++++++++++++++++++---
>  3 files changed, 209 insertions(+), 27 deletions(-)
> 

Hi.  Since this patch set contains use of DPDK's experimental API,
it needs to be based on dpdk-latest branch and have 'dpdk-latest'
in the subject prefix.  OVS doesn't normally use experimental API.
The tunnel offload support was an exception, because it required
significant re-work of the generic code that wasn't feasible to
carry in the dpdk-latest branch.

CC: Ian, dpdk-latest branch might need some rebase.

Also, please, don't send new versions in reply to previous one.
It's only required for dpdk-dev list for some reason, but prohibited
or frown upon in every other list that I know of.  It's very
inconvenient to work this way.

For the patch set itself, a brief look over current state of DPDK
shows that not all drivers that support PORT_ID support the
REPRESENTED_PORT action as well.  I see at least dpaa2 and cnxk
that doesn't.  So, this patch set essentially breaks offloading
for these NICs, IIUC.  Yet another rte_flow inconsistency.
Any plans for addressing that?

Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to