From: Andrew Rybchenko <arybchenko@solarflare.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>,
Dekel Peled <dekelp@mellanox.com>, <wenzhuo.lu@intel.com>,
<jingjing.wu@intel.com>, <bernard.iremonger@intel.com>,
<dev@dpdk.org>, <olivier.matz@6wind.com>,
<adrien.mazarguil@6wind.com>, <thomas@monjalon.net>
Cc: <shahafs@mellanox.com>, <orika@mellanox.com>,
Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Subject: Re: [dpdk-dev] [PATCH v3 1/3] ethdev: support metadata as flow rule criteria
Date: Tue, 9 Oct 2018 17:52:59 +0300 [thread overview]
Message-ID: <6654d2b2-aca4-2202-830a-e6f5853adc48@solarflare.com> (raw)
In-Reply-To: <a5411bfa-9d5f-1e11-645a-c35dd4053260@intel.com>
On 10/9/18 5:46 PM, Ferruh Yigit wrote:
> On 10/5/2018 2:39 PM, Andrew Rybchenko wrote:
>> On 10/5/18 4:31 PM, Ferruh Yigit wrote:
>>> On 9/27/2018 2:57 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.
>>>>
>>>> In order to avoid change in mbuf API, exisitng field buf.hash.fdir.hi
>>>> is used to carry the metadata item. This field is used only in
>>>> 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"
>>>> http://mails.dpdk.org/archives/dev/2018-August/110194.html
>>>>
>>>> Signed-off-by: Dekel Peled <dekelp@mellanox.com>
>>> <...>
>>>
>>>> @@ -526,6 +532,12 @@ struct rte_mbuf {
>>>> uint32_t hi;
>>>> /**< First 4 flexible bytes or FD ID, dependent on
>>>> PKT_RX_FDIR_* flag in ol_flags. */
>>>> + /**
>>>> + * Above member has optional use on egress:
>>>> + * Application specific metadata value
>>>> + * for flow rule match.
>>>> + * Valid if PKT_TX_METADATA is set.
>>>> + */
>>>> } fdir; /**< Filter identifier if FDIR enabled */
>>> Any objection/comment to use hash.fdir.hi for this new "metadata" meaning? Olivier?
>> As for me, I'd prefer to see dedicated union member something like
>> it was suggested in [1].
> Another comment, it was from Cristian while discussing something else, since
> this field is for egress, shouldn't it be somewhere in second cache line
> allocated for Tx?
Tx writes to the first cache-line as well, so I see no problem in using hash
union for Tx. I think it is better to keep remaining space on the second
cache-line for the future use.
>> Andrew.
>>
>> [1] http://mails.dpdk.org/archives/dev/2018-September/111954.html
>>
next prev parent reply other threads:[~2018-10-09 14:53 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-16 13:33 [dpdk-dev] [PATCH " Dekel Peled
2018-09-16 13:33 ` [dpdk-dev] [PATCH 2/3] app/testpmd: " Dekel Peled
2018-09-16 13:33 ` [dpdk-dev] [PATCH 3/3] app/testpmd: add debug command tx_metadata set <port-id> <value> Dekel Peled
2018-09-16 14:37 ` [dpdk-dev] [PATCH v2 0/3] *** SUBJECT HERE *** Dekel Peled
2018-09-27 13:57 ` [dpdk-dev] [PATCH v3 0/3] support meadata as flow rule criteria Dekel Peled
2018-10-03 20:46 ` Thomas Monjalon
2018-10-11 10:49 ` [dpdk-dev] [PATCH v4 " Dekel Peled
2018-10-16 8:42 ` Shahaf Shuler
2018-10-17 12:03 ` [dpdk-dev] [PATCH v5 0/3] support metadata " Dekel Peled
2018-10-21 14:22 ` [dpdk-dev] [PATCH v6 0/2] " Dekel Peled
2018-10-22 16:14 ` Ferruh Yigit
2018-10-21 14:22 ` [dpdk-dev] [PATCH v6 1/2] ethdev: " Dekel Peled
2018-10-21 14:22 ` [dpdk-dev] [PATCH v6 2/2] app/testpmd: support metadata as flow rule item Dekel Peled
2018-10-22 16:13 ` Ferruh Yigit
2018-10-17 12:03 ` [dpdk-dev] [PATCH v5 1/3] ethdev: support metadata as flow rule criteria Dekel Peled
2018-10-17 14:04 ` Andrew Rybchenko
2018-10-17 12:03 ` [dpdk-dev] [PATCH v5 2/3] app/testpmd: support metadata as flow rule item Dekel Peled
2018-10-18 12:26 ` Ori Kam
2018-10-21 13:49 ` Dekel Peled
2018-10-17 12:03 ` [dpdk-dev] [PATCH v5 3/3] app/testpmd: add Tx metadata debug commands Dekel Peled
2018-10-18 7:56 ` Ferruh Yigit
2018-10-18 8:30 ` Dekel Peled
2018-10-11 10:49 ` [dpdk-dev] [PATCH v4 1/3] ethdev: support metadata as flow rule criteria Dekel Peled
2018-10-16 14:11 ` Andrew Rybchenko
2018-10-17 5:27 ` Dekel Peled
2018-10-17 6:02 ` Andrew Rybchenko
2018-10-17 7:52 ` Dekel Peled
2018-10-11 10:49 ` [dpdk-dev] [PATCH v4 2/3] app/testpmd: " Dekel Peled
2018-10-11 10:49 ` [dpdk-dev] [PATCH v4 3/3] app/testpmd: add Tx metadata debug commands Dekel Peled
2018-09-27 13:57 ` [dpdk-dev] [PATCH v3 1/3] ethdev: support metadata as flow rule criteria Dekel Peled
2018-10-05 13:31 ` Ferruh Yigit
2018-10-05 13:39 ` Andrew Rybchenko
2018-10-05 18:20 ` Yongseok Koh
2018-10-08 15:10 ` Dekel Peled
2018-10-09 14:46 ` Ferruh Yigit
2018-10-09 14:52 ` Andrew Rybchenko [this message]
2018-09-27 13:57 ` [dpdk-dev] [PATCH v3 2/3] app/testpmd: " Dekel Peled
2018-09-27 13:57 ` [dpdk-dev] [PATCH v3 3/3] app/testpmd: add debug command Tx metadata set Dekel Peled
2018-10-05 13:27 ` Ferruh Yigit
2018-09-16 14:37 ` [dpdk-dev] [PATCH v2 1/3] ethdev: support metadata as flow rule criteria Dekel Peled
2018-09-18 7:55 ` Xueming(Steven) Li
2018-09-16 14:37 ` [dpdk-dev] [PATCH v2 2/3] app/testpmd: " Dekel Peled
2018-09-18 8:21 ` Xueming(Steven) Li
2018-09-25 11:32 ` Dekel Peled
2018-09-16 14:37 ` [dpdk-dev] [PATCH v2 3/3] app/testpmd: add debug command Tx metadata set Dekel Peled
2018-09-19 5:39 ` Xueming(Steven) Li
2018-10-05 13:19 ` Ferruh Yigit
2018-10-09 14:30 ` Dekel Peled
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6654d2b2-aca4-2202-830a-e6f5853adc48@solarflare.com \
--to=arybchenko@solarflare.com \
--cc=adrien.mazarguil@6wind.com \
--cc=bernard.iremonger@intel.com \
--cc=cristian.dumitrescu@intel.com \
--cc=dekelp@mellanox.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=jingjing.wu@intel.com \
--cc=olivier.matz@6wind.com \
--cc=orika@mellanox.com \
--cc=shahafs@mellanox.com \
--cc=thomas@monjalon.net \
--cc=wenzhuo.lu@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).