On 1/31/23 10:24, Ivan Malov wrote:
Currently, the "pick transfer proxy ethdev" callback is only
advertised for non-representor (in example, main PF) ethdevs.
That does not sit well with the original idea of this method,
which is to let applications discover the privileged port to
use for transfer flow management instead of any given ethdev.
Applications trying to leverage this API on sfc representors
receive an error and cannot configure transfer flow offloads.
Fix the problem by exporting the method to representor ports.
Fixes: 26706314d418 ("net/sfc: implement transfer proxy port callback")
Cc: sta...@dpdk.org
Signed-off-by: Ivan Malov <ivan.ma...@arknetworks.am>
Reviewed-by: Andy Moreton <amore...@xilinx.com>
Reviewed-by: Viacheslav Galaktionov <viacheslav.galaktio...@arknetworks.am>
---
drivers/net/sfc/sfc_flow.c | 4 ++++
drivers/net/sfc/sfc_flow.h | 2 ++
drivers/net/sfc/sfc_repr.c | 10 ++++++++++
3 files changed, 16 insertions(+)
diff --git a/drivers/net/sfc/sfc_flow.c b/drivers/net/sfc/sfc_flow.c
index fb59abd0b5..2937953959 100644
--- a/drivers/net/sfc/sfc_flow.c
+++ b/drivers/net/sfc/sfc_flow.c
@@ -2806,6 +2806,10 @@ const struct rte_flow_ops sfc_flow_ops = {
.pick_transfer_proxy = sfc_flow_pick_transfer_proxy,
};
+const struct rte_flow_ops sfc_repr_flow_ops = {
+ .pick_transfer_proxy = sfc_flow_pick_transfer_proxy,
+};
+
It would be nice to know it is tested in some way.
As far as I can see it can't work since
sfc_flow_pick_transfer_proxy() treats eth_dev->process_private
as struct sfc_adapter_priv, but it is sfc_repr in the case
of sfc representor ethdev. Am I missing something?
