From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id F267D7CBC for ; Tue, 16 Oct 2018 16:12:49 +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-us3.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 9A4EA9800D0; Tue, 16 Oct 2018 14:12:41 +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; Tue, 16 Oct 2018 15:12:32 +0100 To: Dekel Peled , , , , , , , CC: , , , Nikhil Rao References: <1538056677-33846-1-git-send-email-dekelp@mellanox.com> <1539254998-8555-2-git-send-email-dekelp@mellanox.com> From: Andrew Rybchenko Message-ID: Date: Tue, 16 Oct 2018 17:11:52 +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: <1539254998-8555-2-git-send-email-dekelp@mellanox.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-24158.003 X-TM-AS-Result: No-17.309900-8.000000-10 X-TMASE-MatchedRID: Jm7Yxmmj9OkOwH4pD14DsPHkpkyUphL9wx0jRRxcQfP4JyR+b5tvoLB6 KjveEuzJYREd+vD/UBFYFBU0+2PUKQ4mAn6Exf2OA9lly13c/gHmdC4WbBxTJHa2ZEC0WTlX8mi BZ1i+wWsATbU6ENf+542iGm0FA2oFgZi/ORh+nqCxNxaTG4Ot0gQp8uZa2O9n0SxMhOhuA0SlHj sjMHC3hlcEwZrkbL18xdcYjz7XHzWiSIetIxcPtJyebS/i2xjjKx5ICGp/WtGVD1dIAJTXiigIA vPXv5yhRBEtCZSaGbjnvBvu8cgQVIqztqrk0ko7Q1OcCEvT+befM+smQZqWkKvM+zzl/BSTlcme T8st3ycbeOvLuTG9FRRHhVoFID4Zzsxad8fKloYlcqT+ugT9EHzIY7d2+Tz9AnW+Tu2Fi4ZR18Q pzXStTi9BUTTI4YWlioFl5UK3cJ/SduMc6RnI+T5bo3ZLMFMHyouSanPChTSedUv+PWmGO3lEDb 1OO87oNTcc+FGtHL3/voIzhn8wZuVHGbcDbAq6gxsfzkNRlfKTzVw79BoLWCXVtBmyOiKuqIA96 mi6Ci4gGo25AiK7RJYugK/WLR7nbcIlaXgG8W0o7Jk9HABBN+0l0CfaHW6Erthj+vdTyJbbgS7S BBW4zMTU5O4rmQgUyQ+tBSrIFrk= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--17.309900-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24158.003 X-MDID: 1539699163-etVM62n6fJgI 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 14:12:50 -0000 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 [...] > 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? > diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h > index 012577b..933f0e0 100644 > --- a/lib/librte_ethdev/rte_ethdev.h > +++ b/lib/librte_ethdev/rte_ethdev.h > @@ -942,6 +942,11 @@ struct rte_eth_conf { > * for tunnel TSO. > */ > #define DEV_TX_OFFLOAD_IP_TNL_TSO 0x00080000 > +/** > + * Device supports match on metadata Tx offload.. > + * Application must set PKT_TX_METADATA and mbuf metadata field. > + */ > +#define DEV_TX_OFFLOAD_MATCH_METADATA 0x00100000 > > #define RTE_ETH_DEV_CAPA_RUNTIME_RX_QUEUE_SETUP 0x00000001 > /**< Device supports Rx queue setup after device started*/ > diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h > index a50b05c..1fa38db 100644 > --- a/lib/librte_mbuf/rte_mbuf.h > +++ b/lib/librte_mbuf/rte_mbuf.h > @@ -182,6 +182,11 @@ > /* add new TX flags here */ > > /** > + * Indicate that the metadata field in the mbuf is in use. > + */ > +#define PKT_TX_METADATA (1ULL << 41) > + > +/** > * UDP Fragmentation Offload flag. This flag is used for enabling UDP > * fragmentation in SW or in HW. When use UFO, mbuf->tso_segsz is used > * to store the MSS of UDP fragments. > @@ -342,8 +347,9 @@ > PKT_TX_QINQ_PKT | \ > PKT_TX_VLAN_PKT | \ > PKT_TX_TUNNEL_MASK | \ > - PKT_TX_MACSEC | \ > - PKT_TX_SEC_OFFLOAD) > + PKT_TX_MACSEC | \ > + PKT_TX_SEC_OFFLOAD | \ > + PKT_TX_METADATA) > > /** > * Mbuf having an external buffer attached. shinfo in mbuf must be filled. > @@ -511,28 +517,41 @@ struct rte_mbuf { > /** VLAN TCI (CPU order), valid if PKT_RX_VLAN is set. */ > uint16_t vlan_tci; > > + RTE_STD_C11 > union { > - uint32_t rss; /**< RSS hash result if RSS enabled */ > - struct { > - RTE_STD_C11 > - union { > - struct { > - uint16_t hash; > - uint16_t id; > + union { > + uint32_t rss; /**< RSS hash result if RSS enabled */ > + struct { > + union { > + struct { > + uint16_t hash; > + uint16_t id; > + }; > + uint32_t lo; > + /**< Second 4 flexible bytes */ > }; > + uint32_t hi; > + /**< First 4 flexible bytes or FD ID, dependent > + * on PKT_RX_FDIR_* flag in ol_flags. > + */ > + } fdir; /**< Filter identifier if FDIR enabled */ > + struct { > uint32_t lo; > - /**< Second 4 flexible bytes */ > - }; > - uint32_t hi; > - /**< First 4 flexible bytes or FD ID, dependent on > - PKT_RX_FDIR_* flag in ol_flags. */ > - } fdir; /**< Filter identifier if FDIR enabled */ > + uint32_t hi; > + } sched; /**< Hierarchical scheduler */ > + /**< User defined tags. See rte_distributor_process() */ > + uint32_t usr; > + } hash; /**< hash information */ > struct { > - uint32_t lo; > + /** > + * Application specific metadata value > + * for egress flow rule match. > + * Valid if PKT_TX_METADATA is set. > + */ Do I understand correctly that it is in CPU byte order? > + uint32_t tx_metadata; > uint32_t hi; I don't know if we need 'hi' here. Right now only one thing is important - make it clear that it is not used. May be name it 'reserved' instead of 'hi'. It is interesting that hash::sched::hi is used for TxQ identification in rte_event_eth_tx. The patch uses low bytes. So, seem to be fine. However, if the separate structure is added in union for Tx fields, it looks strange taking  rte_event_eth_tx into account. So, I think it would be good document (comments) the purpose of separate but unnamed structure in the union. Andrew.