[RFC] ethdev: add send to kernel action
Checks
Commit Message
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>
---
lib/librte_ethdev/rte_flow.h | 5 +++++
1 file changed, 5 insertions(+)
Comments
> -----Original Message-----
> From: Michael Savisko <michaelsav@nvidia.com>
> Sent: Thursday, 11 August 2022 14:36
>
> 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>
> ---
> lib/librte_ethdev/rte_flow.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> index f92bef0184..969a607115 100644
> --- a/lib/librte_ethdev/rte_flow.h
> +++ b/lib/librte_ethdev/rte_flow.h
> @@ -2853,6 +2853,11 @@ enum rte_flow_action_type {
> * See file rte_mtr.h for MTR profile object configuration.
> */
> RTE_FLOW_ACTION_TYPE_METER_MARK,
> +
> + /*
> + * Send traffic to kernel.
> + */
> + RTE_FLOW_ACTION_TYPE_SEND_TO_KERNEL,
> };
>
> /**
> --
> 2.27.0
Acked-by: Ori Kam <orika@nvidia.com>
Best,
Ori
On 8/11/2022 12:35 PM, Michael Savisko wrote:
> CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.
>
>
> 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?
16/08/2022 11:50, Ferruh Yigit:
> On 8/11/2022 12:35 PM, Michael Savisko wrote:
> > CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.
> >
> >
> > 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.
I replied to it the same day but unfortunately only to the author (see attached). My apologies.
Here's the answer:
"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."
Regards,
Michael
-----Original Message-----
From: Thomas Monjalon <thomas@monjalon.net>
Sent: Monday, 12 September 2022 16:33
To: Michael Savisko <michaelsav@nvidia.com>; Ori Kam <orika@nvidia.com>
Cc: andrew.rybchenko@oktetlabs.ru; dev@dpdk.org; Ferruh Yigit <ferruh.yigit@xilinx.com>; Slava Ovsiienko <viacheslavo@nvidia.com>
Subject: Re: [RFC] ethdev: add send to kernel action
16/08/2022 11:50, Ferruh Yigit:
> On 8/11/2022 12:35 PM, Michael Savisko wrote:
> > CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.
> >
> >
> > 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.
-----Original Message-----
From: Ferruh Yigit <ferruh.yigit@xilinx.com>
Sent: Tuesday, August 16, 2022 12:51 PM
To: Michael Savisko <michaelsav@nvidia.com>; Ori Kam <orika@nvidia.com>; andrew.rybchenko@oktetlabs.ru
Cc: dev@dpdk.org
Subject: Re: [RFC] ethdev: add send to kernel action
On 8/11/2022 12:35 PM, Michael Savisko wrote:
> CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.
>
>
> 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?
On 9/12/22 16:39, Michael Savisko wrote:
>> -----Original Message-----
>> From: Thomas Monjalon <thomas@monjalon.net>
>> Sent: Monday, 12 September 2022 16:33
>> To: Michael Savisko <michaelsav@nvidia.com>; Ori Kam <orika@nvidia.com>
>> Cc: andrew.rybchenko@oktetlabs.ru; dev@dpdk.org; Ferruh Yigit <ferruh.yigit@xilinx.com>; Slava Ovsiienko <viacheslavo@nvidia.com>
>> Subject: Re: [RFC] ethdev: add send to kernel action
>>
>> 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.
Is it a transfer or non-transfer action?
I guess non-transfer, since otherwise the next question is
which kernel...
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 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?
> -----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
13/09/2022 14:09, Michael Savisko:
> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> > On 9/12/22 16:39, Michael Savisko wrote:
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > >> 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.
Should we add this note in the doxygen comment?
This is the wording in the v2 sent today:
+ /*
+ * 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.
+ *
+ * No associated configuration structure.
+ */
+ RTE_FLOW_ACTION_TYPE_SEND_TO_KERNEL,
> > 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.
@@ -2853,6 +2853,11 @@ enum rte_flow_action_type {
* See file rte_mtr.h for MTR profile object configuration.
*/
RTE_FLOW_ACTION_TYPE_METER_MARK,
+
+ /*
+ * Send traffic to kernel.
+ */
+ RTE_FLOW_ACTION_TYPE_SEND_TO_KERNEL,
};
/**