[dpdk-dev] [PATCH v3 1/3] ethdev: support metadata as flow rule criteria

[Andrew Rybchenko]

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 at 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
>>