From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id D824FA00C2; Mon, 26 Sep 2022 15:06:53 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BB06240DF7; Mon, 26 Sep 2022 15:06:53 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id E8B2440695 for ; Mon, 26 Sep 2022 15:06:52 +0200 (CEST) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 3ECB45E; Mon, 26 Sep 2022 16:06:52 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 3ECB45E DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1664197612; bh=QsDtCnMG66aNaIf5A9jHpVixYy6ZQ1ZncVLsIdoVdVk=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=NYxm1YAr2L2nGrwbW9QBPmq2cF74T+CP6XSrBJlKCcy9EWY/LaKbWYo+qys97ZPAQ flqaLXIk2nb+0tsuZ2MsUbxTFKGNRjuh31or6m6Mh4LwDRzfcDDLABqe15w7tQQ5xw yjdUXi4xlgHymdu4ih4Cg8klyhEAXsJFPUc1ovIc= Message-ID: Date: Mon, 26 Sep 2022 16:06:51 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: [PATCH v3] ethdev: add send to kernel action Content-Language: en-US To: Michael Savisko , Ferruh Yigit , Thomas Monjalon Cc: orika@nvidia.com, viacheslavo@nvidia.com, asafp@nvidia.com, Aman Singh , Yuying Zhang , dev@dpdk.org References: <20220914093219.11728-1-michaelsav@nvidia.com> <20220919155013.61473-1-michaelsav@nvidia.com> From: Andrew Rybchenko Organization: OKTET Labs In-Reply-To: <20220919155013.61473-1-michaelsav@nvidia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 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 > --- > 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, > }; > > /**