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 4AD6B42CC4; Thu, 15 Jun 2023 10:38:15 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 08C8B410D0; Thu, 15 Jun 2023 10:38:15 +0200 (CEST) Received: from mail-vk1-f177.google.com (mail-vk1-f177.google.com [209.85.221.177]) by mails.dpdk.org (Postfix) with ESMTP id 3136B40A84; Thu, 15 Jun 2023 10:38:13 +0200 (CEST) Received: by mail-vk1-f177.google.com with SMTP id 71dfb90a1353d-463992996d2so713975e0c.2; Thu, 15 Jun 2023 01:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686818292; x=1689410292; 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=9Tqoa4KbDalXE00+3VD007R0FkXabyg/Nt40/Yq+1Sw=; b=X1zbC7YT1MgBr3qcgetiekhgfxChUplJIwCICmF8Ni0TphtahlySyiyH2GdDTR22ZC /kQsOi+25BJ1rruuXurvbL/wUDPvXMzM1gfS0uLvi5qgjzqUghxjiqEvJNUWHQH72toZ RdGrRvnCE+gdVPGn3coHBcV7ZeoesdBGW5RC4/nQGMlARUjkPDHkOr1E3QVRMy2X7b4h 7IMOXZ9HFCZLtV2XwLtWpigRmJ1uKWyDJxWZnXO2BCmiBwi6TBNnZNUDRMm/WS/71NlD y2j6OPcBrEhqz8ctTO4Je9n+2K9SypiE+OQbA9A7OTOshsjGIxQjijXqWOr6+Z3EIuTC Yn+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686818292; x=1689410292; 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=9Tqoa4KbDalXE00+3VD007R0FkXabyg/Nt40/Yq+1Sw=; b=UrXgTZJPiV1uzMve1t1rFGs0+FLfCwxyYrB/r5wzNxurju8rn/13O8sVaMpkQ6XWG+ vxBZANgxJYlU6rvUcrJYa/yFfkAzufB3uWOUWHB/vDUiGe0AIKokMVEOyGzJWf31O4AL opQZmYEZczG84+LV2pomdBliq4abXNL+Ni9ZqocOrAOH0zeIZXeavAzsKWVhf0wnA7P4 3U79SnlShxHuTfvC+PSqBhrWlHAAMNHTMi8pq1BjEXMIC/6B6ATFCZVagBFMdpo/ezCX y/PULEzqL3YjDrKWEAbCjkfPbjWxOrxfulZZBe45gQbnmVxVg6OJ4yWw6QIJjmygk3jl BXjw== X-Gm-Message-State: AC+VfDy3KuJGgRN0JcM+biHMrUtiKCf9g9Pj0kN9ggkflXIbJiXVINb1 8pJl7Wawey/WcyDcQL8DzTkb2Mb0BuYgDcDPjPw= X-Google-Smtp-Source: ACHHUZ6bZRWp49rbKjtUYPLQ8okmmw0O+adBcEcCAWA45etb9H7Tu6b1lRX/9OSzl6Qp5eoXnHirs0hnU4ol+f1YBqA= X-Received: by 2002:a1f:60c2:0:b0:46e:9f33:add1 with SMTP id u185-20020a1f60c2000000b0046e9f33add1mr1823124vkb.6.1686818292431; Thu, 15 Jun 2023 01:38:12 -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 14:07:46 +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 1:12=E2=80=AFPM Zhang, Qi Z = wrote: > > > > > -----Original Message----- > > From: Jerin Jacob > > Sent: Thursday, June 15, 2023 2:21 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 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 > > > > > > from 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 ea= ch > > fields. > > > > > 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 th= e > > > > compiler. > > > > > This enables the PMD to accept requests from the P4 Runtime and > > > > > reject > > > > 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 from 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 > > > > runtime 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 requi= red to > > provide a channel that connects applications with the hardware responsi= ble > > for implementing the contract. > > > In this context, the PMD (ethdev) serves as the conduit that can fulf= ill this > > requirement. > > > > I meant vdev + rawdev combo can be used to talk to FW. > > OK, I will comment this together when vdev + rawdev be mentioned again at= below. > > > > > > > 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. > > I assume this is just the concern about naming? At least, they are target= to different usage. Not the naming of library. Duplicate functional APIs to express a specific use case for HW. > > > > > > > > > > > > > > For item (2), I think, interest is how to offload p4 workload to > > > > rte_flow. So that _existing_ drivers implements rte_flow can suppor= t > > > > 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 i= nto 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" > > OK I guess the gap here is I may not fully understand is > how we defined the case of item(2) Existing HW and SW drivers implements = rte-flow driver. > > If we assume that the application is not P4-aware, it will consume existi= ng rte_flow API for flow offloading. In this case, all we need to do is imp= lement it in the PMD, which will be a highly hardware-specific task. Do you= propose generalizing this common part? > > On the other hand, if the application is P4-aware, we can assume that the= re won't be a need for translation between P4 tokens and rte_flow protocols= in the PMD. I agree, Translation is BAD. There are two elements to that. 1)if it is p4 aware application, why bother with DPDK abstraction? 2)Can we use compiler techniques to avoid the cost of translation if P4-aware path is needed in DPDK. Rather than creating yet another library. In this context, that would translate to some of your compiler and FW work making as generic so that _any_ other rte_flow based driver can use and improve it. > > > > > > > > > > > We have identified two distinct use cases: > > > > > > P4-Aware Applications: > > > > > > For applications that are already P4 aware, the proposal suggests the > > introduction of a new set of APIs to rte_flow. > > > These APIs aim to facilitate seamless integration between DPDK and P4 > > aware 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. > > We are attempting to generalize the common aspects, considering that P4 R= untime is a standard API. It appears worthwhile to expose certain APIs that= can assist its backend implementation. I agree. If backend is built on top rte_flow and some compiler bits. I think, multiple consumer can use it. Otherwise, we are making the API for a p4 FW backend is needed. > I may need some time to understand the concept of vdev +rawdev combo solu= tion, currently one question in my mind is: in this solution, is above cons= ideration covered? > > Thanks > Qi > > > > > > > > > > > Non-P4 Aware Applications: > > > > > > In the case, our focus is on bridging the existing rte_flow API to th= e > > underlying P4 pipeline. > > > Currently, we haven't identified any significant gaps in the DPDK API= s. > > > 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 the 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 t= o > > > > 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 to 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. >