From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
To: Ivan Malov <ivan.malov@arknetworks.am>, dev@dpdk.org
Cc: stable@dpdk.org, Andy Moreton <amoreton@xilinx.com>,
Viacheslav Galaktionov <Viacheslav.Galaktionov@arknetworks.am>
Subject: Re: [PATCH] net/sfc: export pick transfer proxy callback to representors
Date: Tue, 31 Jan 2023 10:52:20 +0300 [thread overview]
Message-ID: <aec375d9-26bd-7958-c959-1a0714eafdf9@oktetlabs.ru> (raw)
In-Reply-To: <20230131072444.6925-1-ivan.malov@arknetworks.am>
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: stable@dpdk.org
>
> Signed-off-by: Ivan Malov <ivan.malov@arknetworks.am>
> Reviewed-by: Andy Moreton <amoreton@xilinx.com>
> Reviewed-by: Viacheslav Galaktionov <Viacheslav.Galaktionov@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?
next prev parent reply other threads:[~2023-01-31 7:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-31 7:24 Ivan Malov
2023-01-31 7:52 ` Andrew Rybchenko [this message]
2023-01-31 11:08 ` [PATCH v2] " Ivan Malov
2023-01-31 11:13 ` Andrew Rybchenko
2023-02-08 22:06 ` Ferruh Yigit
2023-02-09 7:49 ` Ivan Malov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aec375d9-26bd-7958-c959-1a0714eafdf9@oktetlabs.ru \
--to=andrew.rybchenko@oktetlabs.ru \
--cc=Viacheslav.Galaktionov@arknetworks.am \
--cc=amoreton@xilinx.com \
--cc=dev@dpdk.org \
--cc=ivan.malov@arknetworks.am \
--cc=stable@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).