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 D10E642CB2; Mon, 19 Jun 2023 11:52:45 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A4A7640DF8; Mon, 19 Jun 2023 11:52:45 +0200 (CEST) Received: from mail-vk1-f172.google.com (mail-vk1-f172.google.com [209.85.221.172]) by mails.dpdk.org (Postfix) with ESMTP id 60A6640A81; Mon, 19 Jun 2023 11:52:43 +0200 (CEST) Received: by mail-vk1-f172.google.com with SMTP id 71dfb90a1353d-47151ee3fe6so735590e0c.2; Mon, 19 Jun 2023 02:52:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687168363; x=1689760363; 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=YcL8EuLBmm75nKAj9l5DPRMBtHUbVcF4qWSevAYeWy8=; b=cuXIdm6hGMpNCwt6Rmf+hYWhl7X+X8g7eKDgO+8foe/OJIOtVtQZM0+p7xk9ehiawQ gGj0QTkb1rJzaMNugh6XUKqmFBLwzDGobiLvhlrBFoQZFnbweymYdchU0n0Nz2vmauiw B2XMtGIW2PXNsGUhpiimYgf+UL1giY+hpnFYvEKmbmCx10Qs9KzdLZkklYBxkZOgn1yb wN/O7YUu+6JS6xhPdECDmaKPOKu70JO46lFIf5nadfb08PrWpiYDesIAohfjICz+q0ly czgN9U3wYXFfb5/H0zTzWu4MXEWEXBPyvQqMhVk7VT17V5Bgzjb9IepdAQ4wWFjclhWf b2jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687168363; x=1689760363; 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=YcL8EuLBmm75nKAj9l5DPRMBtHUbVcF4qWSevAYeWy8=; b=Iggt5EMudbNhHakO0mzN4hHFva5IN0qKnAtbypafKEXjhGh2BeQNrgBuRQ7b1pBl9D vCAti2VNvyNu9eXr9zYcdYR7zO45TV/US5qDX1dwTZ8NULQu9TtPhOukBiL/mvGBadSS uqqHY6YGF4YSRGo76GnpV6R8Jms43j79oofCfigKx3VevfWdD/6rmcsGXmTy1gkhcykR EKoBIoRlQtOtnUCGP7/79iYzww52vhAV9FqDCpxrWdu5qSGF62BeRyisip62Q108hozZ HrSc+o0FK2kqXIe2vfs1DcuSHJgwsdJk2gwyvp4iwY1OlsvdLMMfuondvymjSNsAxDWO urlQ== X-Gm-Message-State: AC+VfDxT19xqL6jA0eGHGUHnYUvO/mK/h0UVS5292HTyBaURaow7C6l8 J3pO5gP6W07+fnF1OfQrMfKm7cBOihvZx3hZZfQ= X-Google-Smtp-Source: ACHHUZ55atF/fe49MYbgR+owDOCehunVyO/ZE0DtFLyUB3ZtgIV8uiPuRUcRv0gIsHBF+94D/mZ13VhdXPybR7aGaLk= X-Received: by 2002:a1f:c14e:0:b0:46e:8724:5dbb with SMTP id r75-20020a1fc14e000000b0046e87245dbbmr224751vkf.2.1687168362668; Mon, 19 Jun 2023 02:52:42 -0700 (PDT) MIME-Version: 1.0 References: <20230612111539.462084-1-qi.z.zhang@intel.com> In-Reply-To: From: Jerin Jacob Date: Mon, 19 Jun 2023 15:22:16 +0530 Message-ID: Subject: Re: [RFC] lib/ethdev: introduce table driven APIs To: "Zhang, Qi Z" Cc: "Dumitrescu, Cristian" , 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 Mon, Jun 19, 2023 at 5:53=E2=80=AFAM Zhang, Qi Z = wrote: > > > > > -----Original Message----- > > From: Jerin Jacob > > Sent: Friday, June 16, 2023 9:20 AM > > To: Zhang, Qi Z ; Dumitrescu, Cristian > > > > 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:36=E2=80=AFPM Zhang, Qi Z wrote: > > > > > > > > > > If we assume that the application is not P4-aware, it will consum= e > > > > > existing > > > > rte_flow API for flow offloading. In this case, all we need to do i= s > > > > implement 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 > > > > there won't be a need for translation between P4 tokens and rte_flo= w > > > > 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 i= f > > > > 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. > > > > > > > > > Ok, I would like to gain a better understanding. Below is my current > > understanding: > > > > > > There are no plans to introduce any new API from DPDK. However, your > > proposal suggests the creation of a tool, such as a compiler, which wou= ld > > assist in generating a translation layer from P4 table/actions to rte_f= low for > > user application like p4 runtime backend that based on DPDK. > > > > > > Could you provide more details about the design? Specifically, I woul= d like > > to know what the input for the compiler is and who is responsible for > > generating that input, as well as the process involved. > > > > > > I apologize if I have not grasped the complete picture, but I would > > appreciate your patience. > > > > + @Cristian Dumitrescu > > > > There is already a lot of p4(just based on DPDK lib/pipeline SW, not wi= th any > > HW acceleration) with DPDK. Not sure how much it overlaps, and how clea= n > > is this to integrate with existing SW or "create new one"? > > I would think, enhancing the current p4-dpdk support by using rte_flow > > backend. That would translate to > > 1) Update https://github.com/p4lang/p4c/tree/main/backends/dpdk to > > understand generic p4 table key token to rte_flow token for spec file > > generation. > > OK, I assume that the compiler should have the capability to comprehend t= he logic of the P4 parser and determine the appropriate mapping of each key= field in the P4 table to an rte_flow header. This process should be indepe= ndent of any specific vendor. Yes. > > However, the question arises regarding how to handle vendor-specific data= , which also can be part of the table / action key and could potentially be= mapped to either rte_flow_item_tag or rte_flow_item_metadata. I'm uncertai= n about how the P4-DPDK compiler can manage this aspect. Perhaps this parti= cular aspect should be addressed by each vendor's individual backend compil= er, while we focus on defining the specifications for the output and provid= ing the common components for parser analysis. If we take the compiler path, Why we need vendor specific data? > > > 2) Update https://github.com/p4lang/p4-dpdk-target or introduce common > > library in DPDK to map compiler output (spec file) to rte_flow objects > > invocations. > > I'm not quite sure why we need to update the p4-dpdk-target project, as i= ts purpose is to utilize DPDK for building a software pipeline using P4. Ho= wever, if we do require the introduction of a common library in DPDK, the f= ollowing questions arise: > > 1. What will the API of the library look like? Will it still maintain a t= able-driven interface that is compatible with P4 runtime? What are the key = differences compared to the current proposal? Not sure why we require table driver interface, The common code will parse the compiler output and create the rte_flow objects. > 2. During runtime, will the library load the spec file (output of the com= piler) and construct a mapping from P4 tables/actions to the rte_flow API? = Is my understanding correct? 1) During the library init time, It will parse the spec file and create the specific rte_flow objects 2) When p4 runtime is invoked, data and table name comes over runtime API. The library can do a look-up to find the rte_flow object from name, and do table operations on that object with data provided by the runtime API. > 3. Some hardware vendors already have backend P4 compilers that are capab= le of generating hints for configuring hardware based on tables/actions. Is= it possible to incorporate a "pass-through" mode within this library? Not sure, what is the purpose of this library then in first place, Going back to original question? Why DPDK abstraction of p4 table is needed in DPDK as the p4 is the API contract? Why not a rawdev PMD to leverage EAL services. > > Thanks > Qi >