From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
To: Ori Kam <orika@nvidia.com>,
Michael Savisko <michaelsav@nvidia.com>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: Slava Ovsiienko <viacheslavo@nvidia.com>,
Asaf Penso <asafp@nvidia.com>,
Aman Singh <aman.deep.singh@intel.com>,
Yuying Zhang <yuying.zhang@intel.com>,
"NBU-Contact-Thomas Monjalon (EXTERNAL)" <thomas@monjalon.net>,
Ferruh Yigit <ferruh.yigit@xilinx.com>
Subject: Re: [PATCH v4] ethdev: add send to kernel action
Date: Mon, 3 Oct 2022 13:47:08 +0300 [thread overview]
Message-ID: <2bc61c46-7700-3390-32bb-b0491e9a8766@oktetlabs.ru> (raw)
In-Reply-To: <MW2PR12MB46661545E85829E0A156501ED65B9@MW2PR12MB4666.namprd12.prod.outlook.com>
On 10/3/22 12:57, Ori Kam wrote:
> Hi Andrew,
>
>> -----Original Message-----
>> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>> Sent: Monday, 3 October 2022 12:44
>>
>> On 10/3/22 11:23, Ori Kam wrote:
>>> Hi Andrew
>>>
>>>> -----Original Message-----
>>>> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>>>> Sent: Monday, 3 October 2022 10:54
>>>> On 9/29/22 17:54, Michael Savisko wrote:
>>>>> In some cases application may receive a packet that should have been
>>>>> received by the kernel. In this case application uses KNI or other means
>>>>> to transfer the packet to the kernel.
>>>>>
>>>>> With bifurcated driver we can have a rule to route packets matching
>>>>> a pattern (example: IPv4 packets) to the DPDK application and the rest
>>>>> of the traffic will be received by the kernel.
>>>>> But if we want to receive most of the traffic in DPDK except specific
>>>>> pattern (example: ICMP packets) that should be processed by the
>> kernel,
>>>>> then it's easier to re-route these packets with a single rule.
>>>>>
>>>>> This commit introduces new rte_flow action which allows application to
>>>>> re-route packets directly to the kernel without software involvement.
>>>>>
>>>>> Add new testpmd rte_flow action 'send_to_kernel'. The application
>>>>> may use this action to route the packet to the kernel while still
>>>>> in the HW.
>>>>>
>>>>> Example with testpmd command:
>>>>>
>>>>> flow create 0 ingress priority 0 group 1 pattern eth type spec 0x0800
>>>>> type mask 0xffff / end actions send_to_kernel / end
>>>>>
>>>>> Signed-off-by: Michael Savisko <michaelsav@nvidia.com>
>>>>> Acked-by: Ori Kam <orika@nvidia.com>
>>>>> ---
>>>>> v4:
>>>>> - improve description comment above
>>>> RTE_FLOW_ACTION_TYPE_SEND_TO_KERNEL
>>>>>
>>>>> v3:
>>>>> http://patches.dpdk.org/project/dpdk/patch/20220919155013.61473-1-
>>>> michaelsav@nvidia.com/
>>>>>
>>>>> v2:
>>>>> http://patches.dpdk.org/project/dpdk/patch/20220914093219.11728-1-
>>>> michaelsav@nvidia.com/
>>>>>
>>>>> ---
>>>>> app/test-pmd/cmdline_flow.c | 9 +++++++++
>>>>> doc/guides/testpmd_app_ug/testpmd_funcs.rst | 2 ++
>>>>> lib/ethdev/rte_flow.c | 1 +
>>>>> lib/ethdev/rte_flow.h | 12 ++++++++++++
>>>>> 4 files changed, 24 insertions(+)
>>>>>
>>>>> diff --git a/app/test-pmd/cmdline_flow.c b/app/test-
>> pmd/cmdline_flow.c
>>>>> index 7f50028eb7..042f6b34a6 100644
>>>>> --- a/app/test-pmd/cmdline_flow.c
>>>>> +++ b/app/test-pmd/cmdline_flow.c
>>>>> @@ -612,6 +612,7 @@ enum index {
>>>>> ACTION_PORT_REPRESENTOR_PORT_ID,
>>>>> ACTION_REPRESENTED_PORT,
>>>>> ACTION_REPRESENTED_PORT_ETHDEV_PORT_ID,
>>>>> + ACTION_SEND_TO_KERNEL,
>>>>> };
>>>>>
>>>>> /** Maximum size for pattern in struct rte_flow_item_raw. */
>>>>> @@ -1872,6 +1873,7 @@ static const enum index next_action[] = {
>>>>> ACTION_CONNTRACK_UPDATE,
>>>>> ACTION_PORT_REPRESENTOR,
>>>>> ACTION_REPRESENTED_PORT,
>>>>> + ACTION_SEND_TO_KERNEL,
>>>>> ZERO,
>>>>> };
>>>>>
>>>>> @@ -6341,6 +6343,13 @@ static const struct token token_list[] = {
>>>>> .help = "submit a list of associated actions for red",
>>>>> .next = NEXT(next_action),
>>>>> },
>>>>> + [ACTION_SEND_TO_KERNEL] = {
>>>>> + .name = "send_to_kernel",
>>>>> + .help = "send packets to kernel",
>>>>> + .priv = PRIV_ACTION(SEND_TO_KERNEL, 0),
>>>>> + .next = NEXT(NEXT_ENTRY(ACTION_NEXT)),
>>>>> + .call = parse_vc,
>>>>> + },
>>>>>
>>>>> /* Top-level command. */
>>>>> [ADD] = {
>>>>> diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
>>>> b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
>>>>> index 330e34427d..c259c8239a 100644
>>>>> --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
>>>>> +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
>>>>> @@ -4189,6 +4189,8 @@ This section lists supported actions and their
>>>> attributes, if any.
>>>>>
>>>>> - ``ethdev_port_id {unsigned}``: ethdev port ID
>>>>>
>>>>> +- ``send_to_kernel``: send packets to kernel.
>>>>> +
>>>>> Destroying flow rules
>>>>> ~~~~~~~~~~~~~~~~~~~~~
>>>>>
>>>>> diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
>>>>> index 501be9d602..627c671ce4 100644
>>>>> --- a/lib/ethdev/rte_flow.c
>>>>> +++ b/lib/ethdev/rte_flow.c
>>>>> @@ -259,6 +259,7 @@ static const struct rte_flow_desc_data
>>>> rte_flow_desc_action[] = {
>>>>> MK_FLOW_ACTION(CONNTRACK, sizeof(struct
>>>> rte_flow_action_conntrack)),
>>>>> MK_FLOW_ACTION(PORT_REPRESENTOR, sizeof(struct
>>>> rte_flow_action_ethdev)),
>>>>> MK_FLOW_ACTION(REPRESENTED_PORT, sizeof(struct
>>>> rte_flow_action_ethdev)),
>>>>> + MK_FLOW_ACTION(SEND_TO_KERNEL, 0),
>>>>> };
>>>>>
>>>>> int
>>>>> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
>>>>> index a79f1e7ef0..2c15279a3b 100644
>>>>> --- a/lib/ethdev/rte_flow.h
>>>>> +++ b/lib/ethdev/rte_flow.h
>>>>> @@ -2879,6 +2879,18 @@ enum rte_flow_action_type {
>>>>> * @see struct rte_flow_action_ethdev
>>>>> */
>>>>> RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT,
>>>>> +
>>>>> + /**
>>>>> + * Send packets to the kernel, without going to userspace at all.
>>>>> + * The packets will be received by the kernel driver sharing
>>>>> + * the same device as the DPDK port on which this action is
>>>>> + * configured. This action is mostly suits bifurcated driver
>>>>> + * model.
>>>>> + * This is an ingress non-transfer action only.
>>>>
>>>> May be we should not limit the definition to ingress only?
>>>> It could be useful on egress as a way to reroute packet
>>>> back to kernel.
>>>>
>>>
>>> Interesting, but there are no Kernel queues on egress that can receive
>> packets (by definition of egress)
>>> do you mean that this will also do loopback from the egress back to the
>> ingress of the same port and then
>>> send to kernel?
>>> if so, I think we need a new action "loop_back"
>>
>> Yes, I meant intercept packet on egress and send to kernel.
>> But we still need loopback+send_to_kernel. Loopback itself
>> cannot send to kernel. Moreover it should be two rules:
>> loopback on egress plus send-to-kernel on ingress. Does
>> it really worse it? I'm not sure. Yes, it sounds a bit
>> better from arch point of view, but I'm still unsure.
>> I'd allow send-to-kernel on egress. Up to you.
>>
>
> It looks more correct with loop_back on the egress and send-to-kernel on egress
> I suggest to keep the current design,
> and if we see that we can merge those to commands, we will change it
OK. And the last question: do we need to announce it in release
notes?
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>
>>>
>>>>
>>>>> + *
>>>>> + * No associated configuration structure.
>>>>> + */
>>>>> + RTE_FLOW_ACTION_TYPE_SEND_TO_KERNEL,
>>>>> };
>>>>>
>>>>> /**
>>>
>
next prev parent reply other threads:[~2022-10-03 10:47 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-11 11:35 [RFC] " Michael Savisko
2022-08-15 12:02 ` Ori Kam
2022-08-16 9:50 ` Ferruh Yigit
2022-09-12 13:32 ` Thomas Monjalon
2022-09-12 13:39 ` Michael Savisko
2022-09-12 14:41 ` Andrew Rybchenko
2022-09-13 12:09 ` Michael Savisko
2022-09-14 9:57 ` Thomas Monjalon
2022-09-14 9:32 ` [PATCH v2] " Michael Savisko
2022-09-19 15:50 ` [PATCH v3] " Michael Savisko
2022-09-20 11:08 ` Ori Kam
2022-09-26 13:06 ` Andrew Rybchenko
2022-09-28 14:30 ` Michael Savisko
2022-09-29 14:54 ` [PATCH v4] " Michael Savisko
2022-10-03 7:53 ` Andrew Rybchenko
2022-10-03 8:23 ` Ori Kam
2022-10-03 9:44 ` Andrew Rybchenko
2022-10-03 9:57 ` Ori Kam
2022-10-03 10:47 ` Andrew Rybchenko [this message]
2022-10-03 11:06 ` Ori Kam
2022-10-03 11:08 ` Andrew Rybchenko
2022-10-03 16:34 ` [PATCH v5] " Michael Savisko
2022-10-04 7:48 ` Andrew Rybchenko
2022-09-20 10:57 ` [PATCH v2] " Ori Kam
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=2bc61c46-7700-3390-32bb-b0491e9a8766@oktetlabs.ru \
--to=andrew.rybchenko@oktetlabs.ru \
--cc=aman.deep.singh@intel.com \
--cc=asafp@nvidia.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@xilinx.com \
--cc=michaelsav@nvidia.com \
--cc=orika@nvidia.com \
--cc=thomas@monjalon.net \
--cc=viacheslavo@nvidia.com \
--cc=yuying.zhang@intel.com \
/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).