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 C444742CC2; Thu, 15 Jun 2023 08:21:57 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B384840DDA; Thu, 15 Jun 2023 08:21:57 +0200 (CEST) Received: from mail-vk1-f178.google.com (mail-vk1-f178.google.com [209.85.221.178]) by mails.dpdk.org (Postfix) with ESMTP id C031A40A84; Thu, 15 Jun 2023 08:21:55 +0200 (CEST) Received: by mail-vk1-f178.google.com with SMTP id 71dfb90a1353d-46e92a90610so490145e0c.3; Wed, 14 Jun 2023 23:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686810115; x=1689402115; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=op0gwxZiEo22qQIpEd3iqSGeTYzhVJa61nJSy/6Z5I0=; b=gwkvzneK46nNVihCD8KAXW7EBE6JoGetyuDNc6u/8rAGa7ReTs5tPBOK96SEgEQreZ 6mhqiZtDQvF3jv6UH5Ao6PvTawMbm2XMBY20Ngkxx4HRW4G9t+N6AvG1KZ1SoaadmdAa vbUevVR6juerDmjVEcUpbFbi67AP7WDYhCB7QfSPQmHDSz4ANITYsXPa4G1sgUkpODbU j2qqnbuLdLzu2kecliCjeRZ4QsOZb1HMsbfeKFYO1qpTX1kREKnfWG51OIGcbXBWexBv 9vYufCwPsos3Rk3pxceyZx4mlPCP3Yb17nWb1lQPQ8vY+/XA2VxOyqH2impDrjzwY+EP Gnxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686810115; x=1689402115; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=op0gwxZiEo22qQIpEd3iqSGeTYzhVJa61nJSy/6Z5I0=; b=EtzQgLy843Qf2LdMeGOPZ6eo7SpiItPMZdWTY5NpqyfttsdkpMYuLeXaPaT4rDgx64 FQWNjaOdUsm6XJC1Ebw7u6iV6GP08M8WpjfxIkVJV9lKG4ExzOzEMlf5SrcGlYNDh9eM MX3HqIK2bgfcmp/LIFTIcWjaXOPKittlfVgg7xErqU9HHmIZgHBqnLq2NheAENVa7GqH nIRms+UAJaz3kdFYhjdMnA5JF6HmkAbpH4zt3l+jaM7/iTTF8k8grOWPFojDJtFwIcLR C2393YElOYZX8fmQ7G2eSnrJbD7d+7RAxUhAqDS3MY5fA8VxbYQ0w7vm0rIXTAyuKFkD E+mA== X-Gm-Message-State: AC+VfDw73kZVA2yAMslTK1PAbEiZ/Ckv3Nb4lCXG0bQfj45WXJS4djcH kpOLn8nQEAhJhhPgqx/urGWL3FYYQygxqnsvD50= X-Google-Smtp-Source: ACHHUZ703ZzFdWGcDi7ruAbcBRKwBd/dCfnrYIzLwTcHY7Te7UJhKfbLSGvqawzXI8CR0XzUvcji0T7HNfGtdVURkgc= X-Received: by 2002:a1f:6051:0:b0:464:c5aa:3338 with SMTP id u78-20020a1f6051000000b00464c5aa3338mr7782251vkb.15.1686810114988; Wed, 14 Jun 2023 23:21:54 -0700 (PDT) MIME-Version: 1.0 References: <20230612111539.462084-1-qi.z.zhang@intel.com> In-Reply-To: From: Jerin Jacob Date: Thu, 15 Jun 2023 11:51:28 +0530 Message-ID: Subject: Re: [RFC] lib/ethdev: introduce table driven APIs To: "Zhang, Qi Z" Cc: Ori Kam , "NBU-Contact-Thomas Monjalon (EXTERNAL)" , "david.marchand@redhat.com" , "Richardson, Bruce" , "jerinj@marvell.com" , "ferruh.yigit@amd.com" , "Mcnamara, John" , "Zhang, Helin" , "techboard@dpdk.org" , "dev@dpdk.org" , Ivan Malov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Thu, Jun 15, 2023 at 11:33=E2=80=AFAM Zhang, Qi Z = wrote: > > Hi Jerin: Hi Qi > > > -----Original Message----- > > From: Jerin Jacob > > Sent: Thursday, June 15, 2023 12:58 PM > > To: Zhang, Qi Z > > Cc: Ori Kam ; NBU-Contact-Thomas Monjalon (EXTERNAL) > > ; david.marchand@redhat.com; Richardson, Bruce > > ; jerinj@marvell.com; ferruh.yigit@amd.com; > > Mcnamara, John ; Zhang, Helin > > ; techboard@dpdk.org; dev@dpdk.org; Ivan Malov > > > > Subject: Re: [RFC] lib/ethdev: introduce table driven APIs > > > > On Thu, Jun 15, 2023 at 7:55=E2=80=AFAM Zhang, Qi Z wrote: > > > > > > Hi Ori: > > > > > > Thank you for your review! > > > Comment inline. > > > Please let me know if anything I missed. > > > > > > Thanks > > > Qi > > > > > > > -----Original Message----- > > > > From: Ori Kam > > > > Sent: Thursday, June 15, 2023 2:31 AM > > > > To: Zhang, Qi Z ; NBU-Contact-Thomas Monjalon > > > > (EXTERNAL) ; david.marchand@redhat.com; > > > > Richardson, Bruce ; jerinj@marvell.com; > > > > ferruh.yigit@amd.com > > > > Cc: Mcnamara, John ; Zhang, Helin > > > > ; techboard@dpdk.org; dev@dpdk.org > > > > Subject: RE: [RFC] lib/ethdev: > > > > > > > > Hi Qi, > > > > > > > > > > > > 1. it may be useful to get some general calling flow what comes fro= m > > > > the application, what comes from the compiler. > > > > Simple example will be good. > > > > > > An example of decap VXLAN TCP flow is explained in problem statement > > > (http://mails.dpdk.org/archives/dev/2023-May/267719.html) > > > covering the following information. > > > > > > 1. the p4 source code, the definition of the table and actions 2. the > > > table / action hints generated by the compiler, details to each field= s. > > > 3. How the Control Plane Application utilizes the P4 Runtime API to > > > program the rule with the respective table and action IDs > > > > > > The DPDK PMD is responsible for loading the hints generated by the > > compiler. > > > This enables the PMD to accept requests from the P4 Runtime and rejec= t > > any incompatible request. > > > > I see two different types of device/system category > > > > 1) HW + SW/FW combination that really understands p4 structures and job > > of the driver to is to give work to HW/SW as p4 structure generated fro= m > > vendor specific compiler and runtime gRPC message > > 2) Existing HW and SW drivers implements rte-flow driver. > > > > For item (1), if end user application is using P4 program and P4 runtim= e and > > this is _API contract_ to application, Not sure why end user care it is= DPDK > > PMD or not? > > That's true. DPDK as a platform that manage the hardware, it is required = to provide a channel that connects applications with the hardware responsib= le for implementing the contract. > In this context, the PMD (ethdev) serves as the conduit that can fulfill = this requirement. I meant vdev + rawdev combo can be used to talk to FW. > > If driver writer care about using DPDK for driver framework for > > EAL services, simply using vdev etc would be enough. Right? > > I may not fully understand this, a vdev should have a device type, I didn= 't see any issue for a ethdev vdev to implement the table-driven APIs. See above. There is a lot of overlap between rte_flow and table driven API is the issue. To make things worst, there is also lib/table/ API. > > > > > For item (2), I think, interest is how to offload p4 workload to rte_fl= ow. So > > that _existing_ drivers implements rte_flow can support > > p4 naturally in addition to existing rte_flow API. If that is direction= , then we > > need to the following. > > While the idea of offloading P4 to rte_flow is certainly interesting, it = doesn't seem to directly address our initial problem statement. > The primary objective is to find a solution for offloading rte_flow into = a P4-based pipeline. Isn't same? If not, Please elaborate on "P4 to rte_flow mapping" vs "offloading rte_flow into a P4-based pipeline" > > We have identified two distinct use cases: > > P4-Aware Applications: > > For applications that are already P4 aware, the proposal suggests the int= roduction of a new set of APIs to rte_flow. > These APIs aim to facilitate seamless integration between DPDK and P4 awa= re applications. Counter argument for that is, If the P4 is API contract then why bother with DPDK abstraction use vdev + rawdev talk to FW as PMD is just passing message to FW. FW is doing the heavy lifting anyway. > > Non-P4 Aware Applications: > > In the case, our focus is on bridging the existing rte_flow API to the un= derlying P4 pipeline. > Currently, we haven't identified any significant gaps in the DPDK APIs. > The key challenge lies in handling the translation process within the PMD > > Thanks > Qi > > > > > a)Improve p4-dpdk compiler backend or add new compiler DPDK backend to > > understand the rte_flow and have helper library in DPDK to understand t= he > > compiler spec file to translate to rte_flow objects b)Similar case for = runtime > > API. i.e Have helper functions to translate > > p4 MatchField name etc to appropriate rte_flow objects. > > c)Enhance base rte_flow specification if there are any fundamental gaps= to > > express the new pattern or actions (which is not specific to > > p4 and applicable for any flow matching use case) > > > > If we introduce compiler in the pipeline, a lot of translation will get= in the > > slowpath. And for runtime API, the translation primarily will be name t= o > > rte_flow object lookup (which is not that costly) and using > > rte_flow_template etc. to amortize the cost by making it burst. > > > > Just my 2c.