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 0E35542CD2; Fri, 16 Jun 2023 03:20:29 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8F6CB410ED; Fri, 16 Jun 2023 03:20:28 +0200 (CEST) Received: from mail-vs1-f45.google.com (mail-vs1-f45.google.com [209.85.217.45]) by mails.dpdk.org (Postfix) with ESMTP id 7FD524021E; Fri, 16 Jun 2023 03:20:27 +0200 (CEST) Received: by mail-vs1-f45.google.com with SMTP id ada2fe7eead31-43f5da47667so61522137.3; Thu, 15 Jun 2023 18:20:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686878427; x=1689470427; 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=nbJRMSyuhHgLYmLYOH3e0iODYHbakYty2FLUxWj/v/k=; b=E253JqMJNQkc6vgKR4nNYSXFAfQUmPWsdILAQmCpsu3Rg29zj5SPpJZ/0wsi24GvQB xTLAuTyYxMYngl/Px+cNd8pHQddo6m1pKB/priLR8M3qSogVIY7VZFc1Oc+TQpfSn0An ZWkIX1L8vvYp3hBjKhE9qzT/nsk2FIwOJvJpn1Gu+glCMaXZLnS8G6RhiC7ew/RvFqHs HneBT0smSc24Z4+88rxG8GAQlocQCttK5ZFcMfX5fl4zBlilnOWlT8J72ZubhEJQmrzp eUHsLwHj0KroEC35GgskJS2XGXHR4ZfHzOHpXK1dh1P0IcI+eGKO878yqICjjoXyZhDt rNBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686878427; x=1689470427; 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=nbJRMSyuhHgLYmLYOH3e0iODYHbakYty2FLUxWj/v/k=; b=QzSOTTKLFpGIrKtiSI39I0Mnb42sGxR36RrOfG8XzPyVBE8EAj5MrtNbZ7fYwFT6zp +SjCHAh4fcygE6eL1wJP0RHeT8sVEjVtHrH+Pf/7qHx5ERTdecxIqDQadpbMCxqkxuq6 6pufE0VLqiWdS0nQW/+79EuNAzUluHoVxeR/fqHD5XDLSOXVC2lPeeFVYT5bXuciUHil t9k3KIGoRc+X84LEqrIVtloO2TX7aBXY6Z8CDECof9qgyjlJ1/Wn8FOrWsUuFZAPw7io 6TJyUkzrUWf3LaInyXVqrKIe6k1YuffVYa+l1RJoqZfBi7CRpYjKac6TVpuczoh+eUFR sI+A== X-Gm-Message-State: AC+VfDxFFkGr8UjLbwtBAGG8BmhXIqCoMQTv5c1/ynkPeymZwYe/GEd0 QP8pM+D3ifFLyDzsW3O/HwMI+HpUz6wPTiQCDbI= X-Google-Smtp-Source: ACHHUZ4S3Mv2jCcN/yKdMEvsN0RKH3uvr0Ekfi00+1yEvbD6kpDQF+ay2QiqUSYZ4ZSQl/DZ5SpQ+1S/8dluTxd1xPY= X-Received: by 2002:a67:f9c1:0:b0:43c:8dc1:9df3 with SMTP id c1-20020a67f9c1000000b0043c8dc19df3mr1021435vsq.7.1686878426650; Thu, 15 Jun 2023 18:20:26 -0700 (PDT) MIME-Version: 1.0 References: <20230612111539.462084-1-qi.z.zhang@intel.com> In-Reply-To: From: Jerin Jacob Date: Fri, 16 Jun 2023 06:50:00 +0530 Message-ID: Subject: Re: [RFC] lib/ethdev: introduce table driven APIs To: "Zhang, Qi Z" , Cristian Dumitrescu 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 7:36=E2=80=AFPM Zhang, Qi Z = wrote: > > > > If we assume that the application is not P4-aware, it will consume ex= isting > > rte_flow API for flow offloading. In this case, all we need to do is im= plement > > it in the PMD, which will be a highly hardware-specific task. Do you pr= opose > > 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_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. > > > Ok, I would like to gain a better understanding. Below is my current unde= rstanding: > > There are no plans to introduce any new API from DPDK. However, your prop= osal suggests the creation of a tool, such as a compiler, which would assis= t in generating a translation layer from P4 table/actions to rte_flow for u= ser application like p4 runtime backend that based on DPDK. > > Could you provide more details about the design? Specifically, I would li= ke to know what the input for the compiler is and who is responsible for ge= nerating that input, as well as the process involved. > > I apologize if I have not grasped the complete picture, but I would appre= ciate your patience. + @Cristian Dumitrescu There is already a lot of p4(just based on DPDK lib/pipeline SW, not with any HW acceleration) with DPDK. Not sure how much it overlaps, and how clean 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. 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.