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 378D942F93; Wed, 2 Aug 2023 13:22:06 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BC07140DDB; Wed, 2 Aug 2023 13:22:05 +0200 (CEST) Received: from mail-vs1-f45.google.com (mail-vs1-f45.google.com [209.85.217.45]) by mails.dpdk.org (Postfix) with ESMTP id 6B67E4021D; Wed, 2 Aug 2023 13:22:04 +0200 (CEST) Received: by mail-vs1-f45.google.com with SMTP id ada2fe7eead31-44768e056e1so2307835137.1; Wed, 02 Aug 2023 04:22:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690975323; x=1691580123; 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=/s88MtzY9cZ7YGl/nZ7ubDUC+v9ynM2NGLI0Xs33Gso=; b=Akbvax8CrEruGFqsH8Zqf6+kbbvKz5ALVVT17BM+e2gia/yRjxJHXpoIajpzjFbJuG 1QMYD5k06G7b0ZOMtDcBU1s23bGUo+f9k39VkjVFQn5lYpxO4jh02mqcQZzf08DbExqv +O0jZ3k9kjsZCWhVVzODbqjLhjiVkKP7hXkzg/ShZCXs5GZ8mXt7jA0pYG+woA9mGKsZ kEzX13eBzu0/Znpxt0eSuU27Vp+NbC8qYNVjUcJg5Addr87+MvL8Nsj9Xu9FOFGrZsby oV7ZfYud60U3srOAA7IRYk2jf5m2AyfGYOd6mKBCWRzZCTwS1NHqHwNWijISmabV+tCk hTZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690975323; x=1691580123; 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=/s88MtzY9cZ7YGl/nZ7ubDUC+v9ynM2NGLI0Xs33Gso=; b=fDKUbve0GMd2yjdW1oNs/cERhWuTNLH7aa+najGidy48HHoYT3QDCCGsAUKaBBYAJC 9tX37an/bzjc2rtR5bjNM04Uob1a9pDkYDxsBHzJRWM8wYcal35E/lgB6hxHb8nQBPSv eVF+d9BGk9MifpefFoA5+tapgZU0sSev2KE1NBQNo9HcUe/ZEwPNj/zXT/uFjd+cbdPS 1x9ZdkkXXbPtvJqAh986R3lcDsZIaskcEzZtHsOJGPLPqzNu2sTh7cDITqNfXeJ8wmrE V+MSQa40jPuGzgOSmG7kxEifjEo18e7hRYFjw4NWUb2eQJg2lbgZqbZ8mKm+dtjXAwsD szag== X-Gm-Message-State: ABy/qLZ7WnUXEmsj5A8Xxj/XuiEWASVJGABzih2DeDco8juo4rwuP4pN D4yKDJMYA1UqJs7GlmO33Z8mVepkAzRWSbjv+Pk= X-Google-Smtp-Source: APBJJlFvr79sQC+pIMsKnR2cGpU+QRB3m9p1jkEqFBcjK2mR/I/EI7FjboPFpX86SfQYe4RJ1rDKdNEZtA/b8Jd5TPk= X-Received: by 2002:a67:f04b:0:b0:447:46e7:1343 with SMTP id q11-20020a67f04b000000b0044746e71343mr4698943vsm.23.1690975323710; Wed, 02 Aug 2023 04:22:03 -0700 (PDT) MIME-Version: 1.0 References: <20230802173451.3151646-1-qi.z.zhang@intel.com> <98CBD80474FA8B44BF855DF32C47DC35D87AB8@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35D87AB9@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D87AB9@smartserver.smartshare.dk> From: Jerin Jacob Date: Wed, 2 Aug 2023 16:51:37 +0530 Message-ID: Subject: Re: [PATCH] ethdev: introduce generic flow item and action To: =?UTF-8?Q?Morten_Br=C3=B8rup?= Cc: Qi Zhang , thomas@monjalon.net, orika@nvidia.com, david.marchand@redhat.com, bruce.richardson@intel.com, jerinj@marvell.com, ferruh.yigit@amd.com, techboard@dpdk.org, john.mcnamara@intel.com, helin.zhang@intel.com, dev@dpdk.org, Cristian Dumitrescu 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 Wed, Aug 2, 2023 at 4:31=E2=80=AFPM Morten Br=C3=B8rup wrote: > > > From: Morten Br=C3=B8rup [mailto:mb@smartsharesystems.com] > > Sent: Wednesday, 2 August 2023 12.25 > > > > > From: Qi Zhang [mailto:qi.z.zhang@intel.com] > > > Sent: Wednesday, 2 August 2023 19.35 > > > > > > From: Cristian Dumitrescu > > > > > > For network devices that are programmable through languages such as > > > the P4 language, there are no pre-defined flow items and actions. > > > > > > The format of the protocol header and metadata fields that are used t= o > > > specify the flow items that make up the flow pattern, as well as the > > > flow actions, are all defined by the program, with an infinity of > > > possible combinations, as opposed to being selected from a finite > > > pre-defined list. > > > > > > It is virtually impossible to pre-define all the flow items and the > > > flow actions that programs might ever use, as these are only limited > > > by the set of HW resources and the program developer's imagination. > > > > > > To support the programmable network devices, we are introducing: > > > > > > * A generic flow item: The flow item is expressed as an array of byte= s > > > of a given length, whose meaning is defined by the program loaded by > > > the network device. > > > > The flow item is not "generic", it is "opaque": Only the application kn= ows > > what this flow item does. > > > > I hate the concept for two reasons: > > 1. The inability for applications to detect which flow items the underl= ying > > hardware supports. > > 2. The risk that vendors will use this instead of introducing new flow = item > > types, available for anyone to implement. > > After further consideration, there might be a middle ground. > > Consider Vendor-Specific attributes for DHCP and RADIUS, or SNMP MIBs... > > Any vendor is free to add his own, proprietary special-purpose attributes= , without going through the standardization process. (This is the key chall= enge this patch seems to be aiming at.) > > The vendor might publish these attributes, and other vendors may implemen= t them too. > > And in order to prevent collisions, the Vendor-Specific attributes contai= n a globally unique vendor ID, such as the Private Enterprise Number [1] ma= naged by IANA. > > If similar principles can be worked into the patch, I can support it. +1 > > Preferably, there should also be a means for applications to query if spe= cific Vendor-Specific flow items and actions are supported or not. > > > [1]: https://www.iana.org/assignments/enterprise-numbers/ >