From: Michael Savisko <michaelsav@nvidia.com>
To: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
"NBU-Contact-Thomas Monjalon (EXTERNAL)" <thomas@monjalon.net>,
Ori Kam <orika@nvidia.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
Ferruh Yigit <ferruh.yigit@xilinx.com>,
Slava Ovsiienko <viacheslavo@nvidia.com>
Subject: RE: [RFC] ethdev: add send to kernel action
Date: Tue, 13 Sep 2022 12:09:23 +0000 [thread overview]
Message-ID: <DS0PR12MB6607474085B25BC053A65D2AAB479@DS0PR12MB6607.namprd12.prod.outlook.com> (raw)
In-Reply-To: <64fd910d-f63e-0f5b-ce66-89132671ddbd@oktetlabs.ru>
> -----Original Message-----
> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> Sent: Monday, 12 September 2022 17:41
>
> On 9/12/22 16:39, Michael Savisko wrote:
> >> -----Original Message-----
> >> From: Thomas Monjalon <thomas@monjalon.net>
> >> Sent: Monday, 12 September 2022 16:33
> >>
> >> 16/08/2022 11:50, Ferruh Yigit:
> >>> On 8/11/2022 12:35 PM, 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.
> >>>> This commit introduces rte flow action that the application may use
> >>>> to route the packet to the kernel while still in the HW.
> >>>>
> >>>> Signed-off-by: Michael Savisko <michaelsav@nvidia.com>
> >>>
> >>> I assume this only works for bifurcated drivers, right?
> >>
> >> This question has not been replied after a month.
> >> Please let's be more reactive.
> >
> > Depends on HW. If it can forward packets to different places then it can also
> be supported. But in most cases yes - for bifurcated drivers.
>
> The action sounds like "do some magic". As far as I know we have no concept of
> kernel and cooperation with the kernel in DPDK yet.
There's nothing "magical". Kernel is not a part of DPDK, but DPDK can use KNI to transfer messages between application and kernel.
With bifurcated driver we can have a rule to route the packet 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.
The new action I'm suggesting allows application to route packets directly to the kernel without software involvement, it is a HW offload.
We see it used when working with bifurcated driver, because the kernel driver and the DPDK driver are sharing the same HW.
> Is it a transfer or non-transfer action?
> I guess non-transfer, since otherwise the next question is which kernel...
This is an ingress action only.
> In the case of non-transfer DPDK has a concept of Rx queues which are used to
> deliver traffic to and we have QUEUE and RSS flow actions to do it.
The idea of this offload action is to route traffic away from the DPDK application.
> The patch adds some magic direction "kernel". Don't we want to control
> destination queue? RSS?
> May be we need dedicated control steps to setup kernel Rx queues and than use
> QUEUE/RSS to direct traffic there?
We have no control of how the kernel is configured.
I will provide a new version of the patch with better documentation. Please feel free to suggest any wording.
Thank you,
Michael
next prev parent reply other threads:[~2022-09-13 12:09 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-11 11:35 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 [this message]
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
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=DS0PR12MB6607474085B25BC053A65D2AAB479@DS0PR12MB6607.namprd12.prod.outlook.com \
--to=michaelsav@nvidia.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@xilinx.com \
--cc=orika@nvidia.com \
--cc=thomas@monjalon.net \
--cc=viacheslavo@nvidia.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).