[PATCH v3] ethdev: add send to kernel action

Andrew Rybchenko andrew.rybchenko at oktetlabs.ru
Mon Sep 26 15:06:51 CEST 2022


On 9/19/22 18:50, 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 at 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                       | 10 ++++++++++
>   4 files changed, 22 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..bf076087b3 100644
> --- a/lib/ethdev/rte_flow.h
> +++ b/lib/ethdev/rte_flow.h
> @@ -2879,6 +2879,16 @@ 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

May be it is better to mentioned bifurcated driver model and
add a reference to the documentation.

> +	 * the same device as the DPDK port.

Which DPDK port? There is no control structure associated
with the action.

I guess it is the port used to create the flow rule.
If so, it should be documented that it is non-transfer
action and highlighted that the port used to create
the action.

> +	 * This is an ingress action only.
> +	 *
> +	 * No associated configuration structure.
> +	 */
> +	RTE_FLOW_ACTION_TYPE_SEND_TO_KERNEL,
>   };
>   
>   /**



More information about the dev mailing list