From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <arybchenko@solarflare.com> Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id CEF895B3A for <dev@dpdk.org>; Wed, 17 Oct 2018 08:03:47 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us4.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id DD34E4C008B; Wed, 17 Oct 2018 06:03:44 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 17 Oct 2018 07:03:36 +0100 To: Dekel Peled <dekelp@mellanox.com>, "wenzhuo.lu@intel.com" <wenzhuo.lu@intel.com>, "jingjing.wu@intel.com" <jingjing.wu@intel.com>, "bernard.iremonger@intel.com" <bernard.iremonger@intel.com>, "olivier.matz@6wind.com" <olivier.matz@6wind.com>, Adrien Mazarguil <adrien.mazarguil@6wind.com>, Thomas Monjalon <thomas@monjalon.net>, "ferruh.yigit@intel.com" <ferruh.yigit@intel.com> CC: Shahaf Shuler <shahafs@mellanox.com>, "dev@dpdk.org" <dev@dpdk.org>, "Ori Kam" <orika@mellanox.com>, Nikhil Rao <nikhil.rao@intel.com> References: <1538056677-33846-1-git-send-email-dekelp@mellanox.com> <1539254998-8555-2-git-send-email-dekelp@mellanox.com> <bf16144c-6790-b62a-cdc5-824d4134a1b7@solarflare.com> <VI1PR05MB4224B4F96510DD45FFB0395DB6FF0@VI1PR05MB4224.eurprd05.prod.outlook.com> From: Andrew Rybchenko <arybchenko@solarflare.com> Message-ID: <ee76192e-9d0d-d153-cf19-30c601285d35@solarflare.com> Date: Wed, 17 Oct 2018 09:02:55 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <VI1PR05MB4224B4F96510DD45FFB0395DB6FF0@VI1PR05MB4224.eurprd05.prod.outlook.com> Content-Language: en-GB X-Originating-IP: [91.220.146.112] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24160.003 X-TM-AS-Result: No-21.922000-8.000000-10 X-TMASE-MatchedRID: C/snMIRQLS0OwH4pD14DsPHkpkyUphL9EtdrY/Wb3fM2KlZKA26MkVoq G7y2r1FiYKXU5x6vEGN8SCKVahhnrNHjG9pn3Fnx4Tzr6T25NkdxueIW2fKuyHy/Hx1AgJrrRTG /70PGuyjnKqf2XBK0tNIlI6eMt9ArJuEmNVHRTflIRA38P/dwbuU28KlVaRfjJvtfs8KE419tdM N7/Xh6r5c3tO4W2udE4YS6FyG8vyjyUQNiagGSs9sfxZpQv2qMm/y00tE9Sta/wz3p7pLVvSxZV 2XdhwOw7fNKgmEEsE2S1g+ViNq8vAyG+DOJCLo/iguiJuCNURf4bPjfm0hIQeKYpwtG+wHV8FhG jTp5WPfy/MPf/RmXSoVtgQyPvRbMizFhECDuofD4pTO56aJ0/F+iEcKpKdpuFRlN8zTSzj7az3a yHTONm3Wr3b1YINkH+iwWVZd6tq6wquY0kEgdZ506nVOMOuVpahFQJkAT0vAXiwP0/G+0uqPFjJ EFr+oloTCA5Efyn8AiEOZmeUqhz3Z81v7uPtfWJVcL4MR4q3wAOke9yFcs2VFZJOGjGNRb8ZpKB iTm9R4= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--21.922000-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24160.003 X-MDID: 1539756227-FR3dg8_lgEva Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support metadata as flow rule criteria X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Wed, 17 Oct 2018 06:03:48 -0000 On 10/17/18 8:27 AM, Dekel Peled wrote: > > Thanks, PSB. > > *From:* Andrew Rybchenko <arybchenko@solarflare.com> > *Sent:* Tuesday, October 16, 2018 5:12 PM > *To:* Dekel Peled <dekelp@mellanox.com>; wenzhuo.lu@intel.com; > jingjing.wu@intel.com; bernard.iremonger@intel.com; > olivier.matz@6wind.com; Adrien Mazarguil <adrien.mazarguil@6wind.com>; > Thomas Monjalon <thomas@monjalon.net>; ferruh.yigit@intel.com > *Cc:* Shahaf Shuler <shahafs@mellanox.com>; dev@dpdk.org; Ori Kam > <orika@mellanox.com>; Nikhil Rao <nikhil.rao@intel.com> > *Subject:* Re: [dpdk-dev] [PATCH v4 1/3] ethdev: support metadata as > flow rule criteria > > On 10/11/18 1:49 PM, Dekel Peled wrote: > > As described in [1], a new rte_flow item is added to support metadata > > to use as flow rule match pattern. > > The metadata is an opaque item, fully controlled by the application. > > The use of metadata is relevant for egress rules only. > > It can be set in the flow rule using the RTE_FLOW_ITEM_META. > > An additional item 'tx_metadata' is added in union with existing member > > 'hash' of struct 'rte_mbuf'. > > It is used to carry the metadata item. > > Currently this union is used only for ingress packets, so using it for > > egress metadata will not cause conflicts. > > Application should set the packet metadata in the mbuf dedicated field, > > and set the PKT_TX_METADATA flag in the mbuf->ol_flags. > > The NIC will use the packet metadata as match criteria for relevant > > flow rules. > > This patch introduces metadata item type for rte_flow RTE_FLOW_ITEM_META, > > along with corresponding struct rte_flow_item_meta and ol_flag > > PKT_TX_METADATA. > > [1] "[RFC,v2] ethdev: support metadata as flow rule criteria" > > Signed-off-by: Dekel Peled<dekelp@mellanox.com> <mailto:dekelp@mellanox.com> > > > [...] > > > diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst > > index b600b2d..8643722 100644 > > --- a/doc/guides/prog_guide/rte_flow.rst > > +++ b/doc/guides/prog_guide/rte_flow.rst > > @@ -1191,6 +1191,27 @@ Normally preceded by any of: > > - `Item: ICMP6_ND_NS`_ > > - `Item: ICMP6_ND_OPT`_ > > > > +Item: ``META`` > > +^^^^^^^^^^^^^^ > > + > > +Matches an application specific 32 bit metadata item. > > + > > +- Default ``mask`` matches any 32 bit value. > > + > > +.. _table_rte_flow_item_meta: > > + > > +.. table:: META > > + > > + +----------+----------+---------------------------+ > > + | Field | Subfield | Value | > > + +==========+==========+===========================+ > > + | ``spec`` | ``data`` | 32 bit metadata value | > > + +----------+--------------------------------------+ > > + | ``last`` | ``data`` | upper range value | > > + +----------+----------+---------------------------+ > > + | ``mask`` | ``data`` | zeroed to match any value | > > + +----------+----------+---------------------------+ > > + > > > Is there a difference between any metadata value and > no metadata value at all? > > <DP> Value Zero is considered as no metadata value. > Not sure that I understand. Is flow rule with no META item equivalent to flow rule with META item and mask.data==0? Flow rule with no META item matches packets with and without metadata. Flow rule with META item and mask.data==0 could match packets with metadata provided and any value, or could be equivalent to no META item at all. (I'm asking since no IPv4 item and empty IPv4 item are different things).