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 3A0534221E; Fri, 1 Sep 2023 11:53:13 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C75C4402A6; Fri, 1 Sep 2023 11:53:12 +0200 (CEST) Received: from mail-vk1-f180.google.com (mail-vk1-f180.google.com [209.85.221.180]) by mails.dpdk.org (Postfix) with ESMTP id 594CA40299; Fri, 1 Sep 2023 11:53:11 +0200 (CEST) Received: by mail-vk1-f180.google.com with SMTP id 71dfb90a1353d-48d0dbd62fbso634188e0c.0; Fri, 01 Sep 2023 02:53:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693561990; x=1694166790; darn=dpdk.org; 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=AYRnHS+OrSLxffZ9/jL25dtDcZ2J8PMj0fZDCyiDmXY=; b=qjjg5vi9EymQqweJx3qBoMVuyYPnrZmc11X1GuD4plF8jEr42IAu+cPf3zAfY6zYqu GL7XRqMsF+3iyDvKXrmZOcN612hwHZzgsozvoDaoLyBSRTO8o+0OXb7ICOAFr+epNhHo WQnbZuYuxIrl09QL7bWE3wOndX1kzpLj9lzJSERX0DXgFLM0XZ8Xn9keF8yRoX5tiJaL tij/Dnkyh9CemzE8drOWGu/YU2Hsp1T+G23OJC73D9XbxSoTogFzimJ6mbQJVOiZv6SH 2Tc7ZSHyPQJC1XKhMfje+s0JkgCykoSk4YVYXh2GTYVYYTgG+9Sr4317w7V/iDxxTBsW WiBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693561990; x=1694166790; 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=AYRnHS+OrSLxffZ9/jL25dtDcZ2J8PMj0fZDCyiDmXY=; b=FBma825hb4TVfffCBSrh/RrMIWlBT81bT1Sdg+tNyC+n3AoCMLQM2rAw6a8sV3KOE2 5dNda2Emi8mtq76hUIwsvovxym2vg3sW19D0/Bx2ZFqaD587c25gaU8DzMkxq3+/K7xK 7do+kLXagvtiqUBub0D/A6yWNLavs6VLA8FL2ijK0nyuZoaGZ9mIKyUySkzCDRj6/5g1 a/FgC6Wjbntc8ms7dm270Ku3JK85eLAmVpfOR6HiWjsX9C3AnOtEFubK7peDhDPnoBBZ QlOxa5WIvMkf6vF2o0y+Wk49ctphXeykBTvmAYz/wHqf80drm2HQwpJlcrvaGyUyjSl0 HghA== X-Gm-Message-State: AOJu0YyM/cq6vqi4LwRLRtwQCt5bkRAJ4RKJ5IP/zRBe7zqWGqp77Oej qCSLYqGICN+CJiGN2/3ukQbUMIHjnRDypsAghuE= X-Google-Smtp-Source: AGHT+IFYJCKgCvMZQfTpa6ha9mBtP6eVQAzSJo99sTxUtwlQ/kIs5Sm++YNitinOf9iGRY6d7MCjIyGOoVpwIzuYSII= X-Received: by 2002:a05:6122:c91:b0:490:ca13:8856 with SMTP id ba17-20020a0561220c9100b00490ca138856mr1188102vkb.13.1693561990470; Fri, 01 Sep 2023 02:53:10 -0700 (PDT) MIME-Version: 1.0 References: <20230802173451.3151646-1-qi.z.zhang@intel.com> <98CBD80474FA8B44BF855DF32C47DC35D87ABF@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35D87AC2@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35D87AC4@smartserver.smartshare.dk> <5228976a-5990-bc5c-28d9-b2774abbb783@amd.com> In-Reply-To: From: Jerin Jacob Date: Fri, 1 Sep 2023 15:22:44 +0530 Message-ID: Subject: Re: DPDK community: RTE_FLOW support for P4-programmable devices To: Ori Kam Cc: Ferruh Yigit , "Dumitrescu, Cristian" , =?UTF-8?Q?Morten_Br=C3=B8rup?= , "Zhang, Qi Z" , "NBU-Contact-Thomas Monjalon (EXTERNAL)" , "david.marchand@redhat.com" , "Richardson, Bruce" , "jerinj@marvell.com" , "techboard@dpdk.org" , "Mcnamara, John" , "Zhang, Helin" , "dev@dpdk.org" 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 Fri, Sep 1, 2023 at 12:27=E2=80=AFPM Ori Kam wrote: > > > > > -----Original Message----- > > From: Jerin Jacob > > Sent: Friday, September 1, 2023 5:07 AM > > > > On Thu, Aug 31, 2023 at 4:02=E2=80=AFPM Ori Kam wrot= e: > > > > > > Hi > > > > > > >> > > > > >> 3. Everybody on the call agreed that the P4-programmable devices= from > > > > Intel, > > > > >> AMD and others need to be fully supported by DPDK and that there= are > > > > some > > > > >> gaps in RTE_FLOW to be fixed for supporting these devices. > > > > > > > > > > Personally, It makes sense to me to have normative DPDK API to se= nd p4 > > > > > runtime message to the > > > > > ethdev so that we have "vendor neutral + DPDK based" p4 runtime > > backend. > > > > > > > > > > I prefer to have specialized ethdev ops for this due to the follo= wing > > reasons. > > > > > > > > > > # If the ethdev has both real TCAM based HW(for existing rte_flow > > > > > patterns and actions) and SW agent to receive P4 runtime message = etc. > > > > > Typically, it needs to take a different path in driver to talk. A= ssume, if you > > > > > have cascaded patterns/actions, One is targeted for TCAM and othe= r for > > > > > SW agent for p4, one > > > > > need to have serious amount checking for dispatching.It complicat= es > > > > > the driver and forbid to have > > > > > driver optimization especially cases for templates etc. if user m= aking > > > > > rules for both category of HW. > > > > > > > > > > > > > Indeed I am not against dedicated APIs for P4 runtime backend. > > > > > > > > But assuming there is a dedicated rte_flow item for P4, how it is > > > > different than dedicated API in above scenario? > > > > If driver detects P4 runtime specific rule, it can bail it out to S= W agent. > > > > Can you please elaborate the complexity it introduces? > > > > Assume, normal existing rte-flow programming include a bunch of > > register writes and > > p4 runtime backend is more of SW ring. If a template has both patterns > > and actions > > as cascaded, it will be difficult for driver to optimize the template. > > > > > > > > > > > > > # All we need "char buffer//string" based communication ethdev <-= > app. > > > > > > > > > > > > > Yes, and both a dedicated API or dedicated rte_flow item can provid= e > > > > medium for this communication. > > > > > > > > rte_flow one has flexibility & extensibility advantages, but maybe = not > > > > as straightforward as an API. > > > > > > I think not using the rte_flow will also require duplication of all t= he rule > > handling functions and table creations, for example aync rule create/de= stroy > > query ...... > > > > Yes. That is a fair point. I am OK with exposing as rte_flow. > > As a driver implementation note, to get rid of the above problem, > > driver can choose to have pseudo ethdev devices for p4 if needed(if > > driver finds difficult to combine TCAM based on HW rules and p4 > > runtime rule). > > > > What about the following concept: > The p4 compiler can generate the translation to known PMD objects in rte_= flow, > then when a command is sent from the p4 agent to the offload using GRPC o= r any other way, the DPDK will convert from > p4 protocol to rte_flow commands (this should be very fast since the comm= ands are known and the mapping is already > defined). > > To support the above idea we need to add two new functions to rte_flow (e= ach function will be implemented in PMD level) If the implemention of rte_flow_p4_runtime((p4 command based on the p4 spec= )) is defined in PMD level, The PMD driver to decide to use rte_flow or something else. I think it is good, this is actually going back to specialized API. BTW, rte_flow prefix is not needed in that case. > Rte_flow_register_p4(void *p4_info, void *p4_blob) > { > Creates the static structures/objects > Internal register the p4 commands to PMD translation table. > } > > Rte_flow_p4_runtime(p4 command based on the p4 spec) > { > Based on the registered mapping, translate the command to rte_flo= w commands. > Rte_flow_xxx() calls > } > > As far as I see, the above code will also allow PMD to implement internal= logic if needed, while from DPDK API, > we will only add two new functions. > > > > > >