Re: [dpdk-dev] [PATCH v7 0/5] ethdev: negotiate the NIC's ability to deliver Rx metadata to the PMD

[Ferruh Yigit <ferruh.yigit@intel.com>]

On 10/12/2021 8:46 PM, Ivan Malov wrote:
> In 2019, commit [1] announced changes in DEV_RX_OFFLOAD namespace
> intending to add new flags, RSS_HASH and FLOW_MARK. Since then,
> only the former has been added. The issue has not been solved.
> Applications still assume that metadata features always work
> and do not need to be configured in advance.
> 
> The team behind net/sfc driver has given this problem more thought.
> Conclusions that have been reached are as follows.
> 
> 1. Not all kinds of metadata can be represented by device offload flags.
>     For instance, having flag RSS_HASH is legitimate because the NIC is
>     supposed to actually compute something when this feature is active.
>     However, if similar flag existed for Rx mark, requesting it would
>     not make the NIC actually compute anything. The HW needs external
>     stimuli (flow rules) in order to set the mark in the first place.
> 
> 2. As a consequence of (1), it is apparent that the user's ability to
>     use Rx metadata features is complex and consists of multiple parts:
>     a) the NIC's ability to conduct the flow actions (set metadata);
>     b) the NIC's ability to deliver metadata (if set) to the PMD;
>     c) the PMD's ability to provide metadata received from the
>        NIC to the user by virtue of filling out mbuf fields.
> 
> 3. Aspects (2-a) and (2-c) are already addressed by flow validate API
>     and the procedure of dynamic mbuf field registration respectively,
>     hence, the only problem which really needs a solution is (2-b).
>    
> Patch [1/5] of this series adds a generic API to let the application
> negotiate the NIC's ability to deliver specific kinds of metadata to
> the PMD. This API is supposed to be invoked during initialisation
> period in order to let the PMD configure HW resources which might
> be hard to (re-)configure in the adapter's started state without
> causing traffic disruption and other unwanted consequences.
> 
> [1] c5b2e78d1172 ("doc: announce ethdev API changes in offload flags")
> 
> Changes in v2:
> * [1/5] has review notes from Jerin Jacob applied and the ack from Ray Kinsella added
> * [2/5] has minor adjustments incorporated to follow changes in [1/5]
> 
> Changes in v3:
> * [1/5] through [5/5] have review notes from Andy Moreton applied (mostly rewording)
> * [1/5] has the ack from Jerin Jacob added
> 
> Changes in v4:
> * [1/5] has the API contract clarified to address concerns raised by Ori Kam
> * [1/5] has the API name fixed to use term "metadata" instead of "meta"
> * [1/5] has testpmd loglevel changed as per the note by Ajit Khaparde
> * [1/5] has testpmd code revisited to take multi-process into account
> * [2/5] through [5/5] have the corresponding adjustments incorporated
> 
> Changes in v5:
> * [1/5] has the API comment improved as per the note by Ori Kam
> 
> Changes in v6:
> * Rebase as per request by Ferruh Yigit
> 
> Changes in v7:
> * [5/5] has rebase defect fixed
> 
> Ivan Malov (5):
>    ethdev: negotiate delivery of packet metadata from HW to PMD
>    net/sfc: support API to negotiate delivery of Rx metadata
>    net/sfc: support flow mark delivery on EF100 native datapath
>    common/sfc_efx/base: add RxQ flag to use Rx prefix user flag
>    net/sfc: report user flag on EF100 native datapath
> 

Series applied to dpdk-next-net/main, thanks.