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 7B23D41FDD; Thu, 31 Aug 2023 15:43:03 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 10D9D4028E; Thu, 31 Aug 2023 15:43:03 +0200 (CEST) Received: from mail-vk1-f171.google.com (mail-vk1-f171.google.com [209.85.221.171]) by mails.dpdk.org (Postfix) with ESMTP id 5E4E340285 for ; Thu, 31 Aug 2023 15:43:01 +0200 (CEST) Received: by mail-vk1-f171.google.com with SMTP id 71dfb90a1353d-48d0e739e32so324975e0c.3 for ; Thu, 31 Aug 2023 06:43:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1693489380; x=1694094180; darn=dpdk.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ydyXmRhhCApFVit12E4fsnhUd+MgzfS9PyJiMrgGh5k=; b=X+5IcanaBPhSD8CuelBdp5pdfxOXunkVuPhUlz5wYMxKdaLvXJBWL2g/qAjvlS1w/U 80UQf9p70p0xjLznXOCOU5oswgVl8MJ1ghXjtQAYVzh/Y6R6V4FX7tIwkR4K1pF7QerG ZxEYn6/bSoX+RbuvvBIiSDOAms5SArjM/UzHy8+FFbC9kiUCUVoSqerVAkPJlQS53bGP EicbtYimhoWsKsUE30S9ZVoDObajNbIy/etchZ0NFvVYzlHoFG0cwEAeBctpXXyXe8jG 9ODwGVJo9XOyombWYDmHFKnA26HQifxDP1wKYwvLGVvy8Qbsneazaq54sBxIrmJbH6Mu PqGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693489380; x=1694094180; h=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=ydyXmRhhCApFVit12E4fsnhUd+MgzfS9PyJiMrgGh5k=; b=XCqqB0W1hNlwKiIY2Y12qv1U90pFvkTctW+5QG8RURxrDeIhsfEkcAB2Lgy6NIoARx zmcV3VYbYTOZ0UB3iyvFdTPbpUhxDsHg9qVSC/wneJntaNDYb8TPX/AT5SYw8vT615Ic WBo9x0rIHkU8LQpwFvu37rVdsek6aw5hbSHJzm69+cOUgT4gkURoD0ndP22VxvvFUFR7 rPQqk0gq2ENduWce/Hum6ZYBMduQpOPuVy9+2+S5DxwGLOI/c1vKr5rAHupMKpw8mZy6 MxW5phHFpVi8uwqVTnwUJfoXJ3fvXeXombeJ2H4Wum7pjOaK+Ph5CS4LErBYQknKIoAg azhg== X-Gm-Message-State: AOJu0YyyOmZZ3fvGGN/O3zTQbKgj1JKC45JkyCYAXE+iW0FKmo88FzBu SUUZ7hEHMpMSniCahyWQXq5lDfnZKINh4P93gzdJeg== X-Google-Smtp-Source: AGHT+IHrV4hh/fLuHaxS+H0vUL/er8I+lEym3gH78Slv3Cf8NbEZI0idKThBBFVy+5VJqcwPUluvDnGPrk1jhyyl4PU= X-Received: by 2002:a1f:4e41:0:b0:48d:2779:a4b with SMTP id c62-20020a1f4e41000000b0048d27790a4bmr5348470vkb.2.1693489380508; Thu, 31 Aug 2023 06:43:00 -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: Stephen Hemminger Date: Thu, 31 Aug 2023 15:42:51 +0200 Message-ID: Subject: Re: DPDK community: RTE_FLOW support for P4-programmable devices To: Ori Kam Cc: Ferruh Yigit , Jerin Jacob , "Dumitrescu, Cristian" , =?UTF-8?Q?Morten_Br=C3=B8rup?= , "Zhang, Qi Z" , "NBU-Contact-Thomas Monjalon (EXTERNAL)" , David Marchand , "Richardson, Bruce" , Jerin Jacob , techboard@dpdk.org, "Mcnamara, John" , "Zhang, Helin" , dev Content-Type: multipart/alternative; boundary="000000000000f4dd20060438383f" 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 --000000000000f4dd20060438383f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It also introduces lots of new test conditions. For example, can a P4 flow be deleted, supersed, or read by a flow created by rte_flow. On Thu, Aug 31, 2023, 12:32 PM Ori Kam wrote: > Hi > > > -----Original Message----- > > From: Ferruh Yigit > > Sent: Tuesday, August 29, 2023 1:18 PM > > devices > > > > On 8/29/2023 8:38 AM, Jerin Jacob wrote: > > > On Mon, Aug 28, 2023 at 9:43=E2=80=AFPM Dumitrescu, Cristian > > > wrote: > > >> > > >>>> We just set up a community call for next week to discuss in more > details > > the > > >>>> proposal for RTE_FLOW extensions to support P4-programmable device= s > > >>>> https://mails.dpdk.org/archives/dev/2023-August/273703.html and > look > > for > > >>>> ways to converge and make progress. > > >>>> > > >>>> All the people from To: and CC: are already invited. To avoid > cluttering > > >>> people's > > >>>> calendars, I did not add dev@dpdk.org, so if anybody else wants to > attend, > > >>>> please send me a private email and I will be happy to forward the > invite. > > >>>> > > >>>> Thanks, > > >>>> Cristian > > >> > > >> Attendees: Morten Brorup, Jerin Jacob, Anoob Joseph, Vipin Varghese, > Qi > > Zhang, > > >> Cristian Dumitrescu > > >> > > >> 1. Ori (RTE_FLOW maintainer) and others were not present, probably o= n > > vacation, > > >> hopefully they will be able to attend the next call on this topic. > Ferruh had a > > last > > >> minute conflict that he could not avoid. > > >> > > >> 2. Cristian presented a few slides (attached) with the problem > statement, > > current > > >> RTE_FLOW gaps for P4-programmable devices and the list of current > > solution > > >> proposals. > > >> > > >> 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 > backend. > > > > > > 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. > Assume, 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 > agent. > > Can you please elaborate the complexity it introduces? > > > > > # 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 > rule handling functions and table creations, for example aync rule > create/destroy query ...... > > --000000000000f4dd20060438383f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It also introduces lots of new test conditions. For examp= le, can a P4 flow be deleted, supersed, or read by a flow created by rte_fl= ow.

On Thu, Aug 31, 2023, 12:32 PM Ori Kam <orika@nvidia.com> wrote:
Hi

> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@amd.com>
> Sent: Tuesday, August 29, 2023 1:18 PM
> devices
>
> On 8/29/2023 8:38 AM, Jerin Jacob wrote:
> > On Mon, Aug 28, 2023 at 9:43=E2=80=AFPM Dumitrescu, Cristian
> > <cristian.dumitrescu@intel.com> wrote:
> >>
> >>>> We just set up a community call for next week to disc= uss in more details
> the
> >>>> proposal for RTE_FLOW extensions to support P4-progra= mmable devices
> >>>> https://= mails.dpdk.org/archives/dev/2023-August/273703.html and look
> for
> >>>> ways to converge and make progress.
> >>>>
> >>>> All the people from To: and CC: are already invited. = To avoid cluttering
> >>> people's
> >>>> calendars, I did not add dev@dpdk.org, so if anybody el= se wants to attend,
> >>>> please send me a private email and I will be happy to= forward the invite.
> >>>>
> >>>> Thanks,
> >>>> Cristian
> >>
> >> Attendees: Morten Brorup, Jerin Jacob, Anoob Joseph, Vipin Va= rghese, Qi
> Zhang,
> >> Cristian Dumitrescu
> >>
> >> 1. Ori (RTE_FLOW maintainer) and others were not present, pro= bably on
> vacation,
> >> hopefully they will be able to attend the next call on this t= opic. Ferruh had a
> last
> >> minute conflict that he could not avoid.
> >>
> >> 2. Cristian presented a few slides (attached) with the proble= m statement,
> current
> >> RTE_FLOW gaps for P4-programmable devices and the list of cur= rent
> solution
> >> proposals.
> >>
> >> 3. Everybody on the call agreed that the P4-programmable devi= ces from
> Intel,
> >> AMD and others need to be fully supported by DPDK and that th= ere 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 SW a= gent.
> Can you please elaborate the complexity it introduces?
>
> > # All we need "char buffer//string" based communication= ethdev <-> app.
> >
>
> 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 rul= e handling functions and table creations, for example aync rule create/dest= roy query ......

--000000000000f4dd20060438383f--