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 06D7B42219; Fri, 1 Sep 2023 04:07:54 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 89BAD40298; Fri, 1 Sep 2023 04:07:53 +0200 (CEST) Received: from mail-vk1-f179.google.com (mail-vk1-f179.google.com [209.85.221.179]) by mails.dpdk.org (Postfix) with ESMTP id 60FC54014F; Fri, 1 Sep 2023 04:07:52 +0200 (CEST) Received: by mail-vk1-f179.google.com with SMTP id 71dfb90a1353d-48d0e739e32so567391e0c.3; Thu, 31 Aug 2023 19:07:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693534071; x=1694138871; 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=1ln0G/zVcTykP7xJavfUOyfZVdcemhKQxtJJlEjGbeE=; b=G0jlA33CHUluUyfJy03QWGkQ+3xvjGhX98E2a0ZNEH0EAgydzZdZeQ4wvpXo6SdR0A 4aYqZVbPd1VW1SCUgea/IQLr2mxApY3s/HaXrt1BdaEjbqdBQWsoXIYWMFvFUnLzBfE4 pMTxdhhmYU1ABGe9RUkLyp0Dka4TpE/1adcg/bbcLoP52gg/WKGxzPnQ8PYOJ9DL+DSV DlOuv9SPTpOob1FSVXn9Wa4/oGMAg8XdC+JiTsi4avx62uc+CKuMLwRDn9WwvaYJ+Bd3 La+p8i4l8mKocdBLc6Uw3D12GS18XAazzNeRtQhFwZ7i1fQ36HelUYl5SgL+mbljR7ny rN8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693534071; x=1694138871; 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=1ln0G/zVcTykP7xJavfUOyfZVdcemhKQxtJJlEjGbeE=; b=ALA5Ig/T7cxckFTrfLPDuDKx8XJNaF1c+56z8anDsjAtgE9HRF/UoPJiZSHCi+SIEj CiQYOUGyZDPyg6LAgltBWEp1MO/sn3VyoHU2mHeCKEOigMiqXaA29rc4FWsuLKIpkWCh wfGW87dVSp2sV6mW3n8TPO2hDg1Ml6pBPCnNukICYM143fidszm1QsEPEE4HTh9ECIpM I9Fmf+/BphU3dxby6ZTZzkwpExN9BDAXMHfDKGuzrqzLz5gPyGZO9/uV0a3CksFcFQhl 0h1pv14Mq0OV3dz9NckM2BDiKCXFUEohNhfPzLso4C4pLJHkcRnokTFnMlEJAiyIJc+H TC1g== X-Gm-Message-State: AOJu0YyUcLSJsDVZII1VqwGv2un5JC2QkXIlBVAOoDHbvfwBiKn0CH+V bUuQc3Ct5nA3Kb9dDgxE10mg/0o37KP1c83fpxw= X-Google-Smtp-Source: AGHT+IEIYC2rTiOZ5B/bY+KDxPHaGJz5Z0TlbIEI8p9gftZmX6XDADCbOr+Fk2Bg8vVusVbvkq65ydT2IYx6Z0D+Wl0= X-Received: by 2002:a1f:c982:0:b0:48f:e2eb:6dd2 with SMTP id z124-20020a1fc982000000b0048fe2eb6dd2mr1368741vkf.9.1693534071626; Thu, 31 Aug 2023 19:07:51 -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 07:37:25 +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 Thu, Aug 31, 2023 at 4:02=E2=80=AFPM Ori Kam wrote: > > Hi > > >> > > >> 3. Everybody on the call agreed that the P4-programmable devices fro= m > > 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 send p= 4 > > > runtime message to the > > > ethdev so that we have "vendor neutral + DPDK based" p4 runtime backe= nd. > > > > > > I prefer to have specialized ethdev ops for this due to the following= 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. Assum= e, if you > > > have cascaded patterns/actions, One is targeted for TCAM and other fo= r > > > SW agent for p4, one > > > need to have serious amount checking for dispatching.It complicates > > > the driver and forbid to have > > > driver optimization especially cases for templates etc. if user makin= g > > > 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 SW ag= ent. > > 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 <-> ap= p. > > > > > > > Yes, and both a dedicated API or dedicated rte_flow item can provide > > 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 the r= ule 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). >