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 A6FE542B8E; Wed, 24 May 2023 17:00:41 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9A5FA4282D; Wed, 24 May 2023 17:00:41 +0200 (CEST) Received: from mail-vk1-f169.google.com (mail-vk1-f169.google.com [209.85.221.169]) by mails.dpdk.org (Postfix) with ESMTP id EFDC4400EF; Wed, 24 May 2023 17:00:39 +0200 (CEST) Received: by mail-vk1-f169.google.com with SMTP id 71dfb90a1353d-457493916bfso729156e0c.3; Wed, 24 May 2023 08:00:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684940439; x=1687532439; 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=/WA9+3r4unObLzrW93dL2sNjUJw1K+dIGqZ9tYYvxnA=; b=Sn4G9fODSQiWGmjqYB8t8YZacBOmoF1Iw6J5ovfa7nf5H7Qxo1MWOkBjYtROt+gQlN ENYPIVrqnkeVkpZ7Z8r9+XAxd9/W2Y8QtkbAUNmUMF+BKEFIF+2o6urS4HmBQYhKKjDF g3cYYKhCDAeqZxBHypmf09rIDfXyPIbGZfsfH8fF5Kbf9j+9+D49QyFYq2Fgnmit0M+l Ln3jmRz0XoODbi/VNrN9WCji4iyRqz/On8eMfdX8+QdqfJULOxcPdCUxJ3iwCdm/gX52 YBtThA4QK1LBwfkruXH4TrPcGBjE5rAbYAXH7pXcs9/+xwqayLUzESMmmNuSTcJVHxFd Kn1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684940439; x=1687532439; 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=/WA9+3r4unObLzrW93dL2sNjUJw1K+dIGqZ9tYYvxnA=; b=jMKupLVFvdiCnFMYxBttN/abQQOUoQ7cM2E7x4rtcioLnspEtlzGhHcgPXJ3XZR0NW Qq5UAqvo9Hw6Kj7PN6Ty0WDjFG5kCKpvsbQVlhmoFO2B60pkE5PDf/AcIttluFIK0hFh jSbWaVQuz0G2mraZixMY7CM5nglIr2ly/zmA+29YpmynT4MBCeYVKRxGddvJqqfDdzHi hvpVxkkp1pc0uIgy4rEO7SCKRTCjNpUBOGn4FZVsuIgLtcS8G1AGp5WV3tcQZoIYKUR2 Et3LRLMoLGRoNrcTtFsMB5MFuG7xs2E2DV64/plbX3pL7h2feI90tpvoVtE/7P0uIR5U MPiw== X-Gm-Message-State: AC+VfDxiWEQoPY7XqhKKgZbYUY1eVjo+2Pu6r4ngHLSYI0xWGyvonkka 7/8nNrL8jkoh60COJIstC9Hflrcxxgna2+fo9V4= X-Google-Smtp-Source: ACHHUZ7EXlmWjb2Vj32m9AdYxGm6+VVc2cWs11Yz6O+lAkRrxTBXrD3WnqNJgsO82HNnRQWjnFKBebnDW2CuCb17t7M= X-Received: by 2002:a1f:c682:0:b0:457:2a78:122e with SMTP id w124-20020a1fc682000000b004572a78122emr5983555vkf.14.1684940439122; Wed, 24 May 2023 08:00:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jerin Jacob Date: Wed, 24 May 2023 20:30:13 +0530 Message-ID: Subject: Re: seeking community input on adapting DPDK to P4Runtime backend To: "Zhang, Qi Z" Cc: Ori Kam , "dev@dpdk.org" , "techboard@dpdk.org" , "Richardson, Bruce" , "Burakov, Anatoly" , "Wiles, Keith" , "Liang, Cunming" , "Wu, Jingjing" , "Zhang, Helin" , "Mcnamara, John" , "Xu, Rosen" , Kiran Kumar K , Satheesh Paul 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, May 22, 2023 at 10:42=E2=80=AFAM Zhang, Qi Z = wrote: > > > > > -----Original Message----- > > From: Ori Kam > > Sent: Thursday, May 18, 2023 10:34 PM > > To: Zhang, Qi Z ; dev@dpdk.org > > Cc: techboard@dpdk.org; Richardson, Bruce ; > > Burakov, Anatoly ; Wiles, Keith > > ; Liang, Cunming ; Wu, > > Jingjing ; Zhang, Helin ; > > Mcnamara, John ; Xu, Rosen > > > > Subject: RE: seeking community input on adapting DPDK to P4Runtime > > backend We did some study to use rte_flow on table driven _HW_ (HW has similar capability to p4 table) Following are the observations that need improvement in rte_flow. 1) HW engines require more resources for ACL (considering the algorithmic HW implementation and table size is in handful of millions), whereas EM, LPM needs less HW resources, In p4, we have means to express this, in rte_flow, in general assumption it is ACL. We may need to express the mode in rte_flow_template_table_create() or so. Otherwise, more than one rte_flow_pattern_template* templates pattern_template_index of rte_flow_async_create() creates conflicting modes. In p4, mode is associated with a table, and it has fixed KEY and VALUE. This area in the rte_flow requires improvement if we need to use with p4 type HW. 2) rte_flow is purely in working "inline" mode, If CPU core needs to do lookup on the table created. We require some APIs to look-aside mode support. 3) Handling of raw action data a) In p4, Action value is opaque, so maybe we need to have action RAW where value can be running number from 0 to VALUE - 1. b) Expressing the handling compute operation after lookup. rte_flow_actions are fixed in nature, which would suffice for a lot of use case. Expressing the following case may be difficult with rte_flow now. For example: value_from_lookup =3D lookup(packet, key); if ((packet.filed[x] && value_value_from_lookup) =3D=3D value_x) { packet.field[x] +=3D value_y; packet.field[x] ^=3D value_z; } I think, such general programming paradigm kind of action may need ePBF kind program to express. Where we can add new RTE_FLOW_ACTION_LOAD_EPF_PROGRAM to run through a simple program after table lookup. Either, we can update the rte_flow to address the cases reported in the thr= ead or enhance the current rte_table library(which already has a function pointer based backend) and create an object using the rte_table API and connect the table object with rte_flow API. I think, we should try to enhance rte_flow for more native table support if possible.