[0/5] A means to negotiate support for Rx meta information

  Back in 2019, commit c5b2e78d1172 ("doc: announce ethdev API changes in offload flags")
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. Currently, there's no way for
the application to configure the ethdev's ability to read out user FLAG, user MARK or
whatever else meta information that might be required in the case of tunnel offload.
The application assumes that no extra efforts are needed to make such data available.

The team behind sfc poll-mode driver would like to take over these efforts since the
lack of said controls has started impacting us in a number of ways. Riverhead, a
cutting edge Xilinx smart NIC family, allows to switch between several Rx prefix
formats, with the short one being the most suited for small packet performance.
Features like RSS hash and user mark, in turn, are provided when long prefix is used,
but the driver does not enable it by default. Some leverage has to be implemented to
let the application express its interest in relying on various sorts of Rx meta data.

Our research indicates that, while RSS_HASH is a legitimate offload flag (it requests
the very computation of RSS hash and not just its delivery via mbufs), adding similar
flags for user FLAG, user MARK and tunnel ID information has a better alternative.

The first patch in the series provides a dedicated API to control precisely the very
ability to deliver Rx meta data from the HW to the ethdev and, later, to the callers.
While adding a new dedicated API might at first seem a bit awkward, it does have its
benefits, with the most notorious one being its clear and concise contract for users.
The documentation provided in the patch explains concrete workflow to be implemented.

The most important use case for this might be Open vSwitch. The application has to be
patched separately to make use of the new API. Right now OvS tries to use tunnel
offload and, if it fails to insert the corresponding flow rules, falls back to
MARK + RSS scheme, which also can fail in the case when the port doesn't support MARK.
With this API, OvS will be able to negotiate supported types of Rx meta information
in advance thus avoiding many unnecessary flow insertion attempts later on.

Ivan Malov (5):
  ethdev: add API to negotiate support for Rx meta information
  net/sfc: provide API to negotiate supported Rx meta features
  net/sfc: allow to use EF100 native datapath Rx mark in flows
  common/sfc_efx/base: add RxQ flag to use Rx prefix user flag
  net/sfc: allow to discern user flag on EF100 native datapath

 drivers/common/sfc_efx/base/ef10_rx.c  | 54 +++++++++++++--------
 drivers/common/sfc_efx/base/efx.h      |  4 ++
 drivers/common/sfc_efx/base/rhead_rx.c |  3 ++
 drivers/net/sfc/sfc.h                  |  2 +
 drivers/net/sfc/sfc_ef100_rx.c         | 19 ++++++++
 drivers/net/sfc/sfc_ethdev.c           | 34 +++++++++++++
 drivers/net/sfc/sfc_flow.c             | 10 ++--
 drivers/net/sfc/sfc_mae.c              | 22 ++++++++-
 drivers/net/sfc/sfc_rx.c               |  6 +++
 lib/ethdev/ethdev_driver.h             | 19 ++++++++
 lib/ethdev/rte_ethdev.c                | 25 ++++++++++
 lib/ethdev/rte_ethdev.h                | 66 ++++++++++++++++++++++++++
 lib/ethdev/version.map                 |  3 ++
 13 files changed, 239 insertions(+), 28 deletions(-)