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 7A1B742D02; Tue, 20 Jun 2023 07:07:25 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6A23A40EDF; Tue, 20 Jun 2023 07:07:25 +0200 (CEST) Received: from mail-qv1-f45.google.com (mail-qv1-f45.google.com [209.85.219.45]) by mails.dpdk.org (Postfix) with ESMTP id 3EFC1400D6; Tue, 20 Jun 2023 07:07:24 +0200 (CEST) Received: by mail-qv1-f45.google.com with SMTP id 6a1803df08f44-62ffe4cabc0so29798846d6.1; Mon, 19 Jun 2023 22:07:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687237643; x=1689829643; 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=5S3BoQlMs+oBH7hWIeBTGjOZUO/Zl5SXRriLUrJCuvI=; b=OlxGrFHfv3NKsnQv5FjJGFvNhB9/MxYx1xwQ20J2sapHdVMzXSaB3mR5wAw22OAK3g FUfqjeSrmV0xFiu0d/CRIPh02vwgGs9wLj33g3juAfzLmJU2Mukro7nuGaOlC6RebTPK WDixeNHoVn1b0voGqNiOXkYNUya7+ojWEIfjxE1F21ybiy3BXsLp51O5HTfvo3fZ2tN/ jt4JQTcDLFYBDdZIEwAKQD8iIIcyC6toGH8vvcn8IvHI2Pu9DuHQlelHFmOVfwX7nqkK UesHWXHwgIMgnAP/c7iC2pmCgLLoisEanne4Fymqv72UZ2lgtN/F38W5xoYZ8rgfqfYh ptvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687237643; x=1689829643; 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=5S3BoQlMs+oBH7hWIeBTGjOZUO/Zl5SXRriLUrJCuvI=; b=AG7njRAd1lHejz1gKzXSCSNoc1Hgm/En5j9vsm2Wi3wsiInQFaYeHRuC60wWysTqb/ q/dsH5B11WghpzS9wMwmzd5cD7dYZKANdvaEpeXe9BplmupAUSF6OE7a6zrBWstM5kH4 igycGh4XLN/lt03E3AlgJhW0Kiwg6XsEFMbpDoDfa642BJIBpsLMKgltP2EUrJkEw5pj DuQKZql03MsAKMO7CxSKYBG2qG06IOASb1DfMQM05TbvBColyyAK4bQWwqHss6zTkOAA hqpox+FQDR2YE2LD41GJZbvxzlTD2I4zPqDHAElr+sPbrL1p7UJ+d8AWGkmrTQB6k1Yq 5dJw== X-Gm-Message-State: AC+VfDxRm7edMSDBn4Z61dBVq+m+3+lKp/lFQVvUuX6vshOiOtR85TMa vjhxWgPCMl3PQQluWaVOrABwB8JLPbmD5BRGXb8= X-Google-Smtp-Source: ACHHUZ7qUZI2VLgCKYc3WskJN8uZOpegs7Kg3Zyhx3bJbvhQHELGdH18ngSpCKbzIQVgdhhS/apiJOBhHNfOAoGT2hc= X-Received: by 2002:a05:6214:2486:b0:630:20d8:7576 with SMTP id gi6-20020a056214248600b0063020d87576mr5772611qvb.59.1687237643581; Mon, 19 Jun 2023 22:07:23 -0700 (PDT) MIME-Version: 1.0 References: <20230612111539.462084-1-qi.z.zhang@intel.com> In-Reply-To: From: Jerin Jacob Date: Tue, 20 Jun 2023 10:36:57 +0530 Message-ID: Subject: Re: [RFC] lib/ethdev: introduce table driven APIs To: "Zhang, Qi Z" Cc: "Dumitrescu, Cristian" , 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 Tue, Jun 20, 2023 at 7:22=E2=80=AFAM Zhang, Qi Z = wrote: > > > > > -----Original Message----- > > From: Jerin Jacob > > Sent: Monday, June 19, 2023 5:52 PM > > To: Zhang, Qi Z > > Cc: Dumitrescu, Cristian ; 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 > > > > Subject: Re: [RFC] lib/ethdev: introduce table driven APIs > > > > On Mon, Jun 19, 2023 at 5:53=E2=80=AFAM Zhang, Qi Z wrote: > > > > > > > > > > > > > -----Original Message----- > > > > From: Jerin Jacob > > > > Sent: Friday, June 16, 2023 9:20 AM > > > > To: Zhang, Qi Z ; Dumitrescu, Cristian > > > > > > > > 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 > > > > Subject: Re: [RFC] lib/ethdev: introduce table driven APIs > > > > > > > > > > > > However, the question arises regarding how to handle vendor-specific = data, > > which also can be part of the table / action key and could potentially = be > > mapped to either rte_flow_item_tag or rte_flow_item_metadata. I'm > > uncertain about how the P4-DPDK compiler can manage this aspect. Perhap= s > > this particular aspect should be addressed by each vendor's individual > > backend compiler, while we focus on defining the specifications for the > > output and providing the common components for parser analysis. > > > > If we take the compiler path, Why we need vendor specific data? > > Let's consider the following scenario: > > Assume that a hardware device contains metadata that can be passed betwee= n different stages of a pipeline. > > For instance, in stage A, a rule is matched, and the metadata is set. In = stage B, this metadata is used as a match key. > > To design the API calls for the above situation using rte_flow, my unders= tanding is that we need to map a rte_flow_item_tag or rte_flow_item_metadat= a to the corresponding metadata portion (including offset and size). > This way, the driver can understand how to configure the hardware accordi= ngly. > > In P4, we define data structures to abstract the metadata, and the vender= specific-backend compiler determines the arrangement of the metadata space= . > > However, in our case, how does the proposed compiler establish the mappin= g from the P4 metadata key to rte_flow without support from the backend com= piler? Yes. We need to change the backend compiler to understand the rte_flow mapping to p4 to avoid any translation cost.