Re: [dpdk-dev] [RFC] ethdev: reserve the RX offload most-significant bits for PMD scartch

[Stephen Hemminger <stephen@networkplumber.org>]

On Thu, 20 Jun 2019 15:25:52 +0800
Haiyue Wang <haiyue.wang@intel.com> wrote:

> Generally speaking, the DEV_RX_OFFLOAD_xxx for RX offload capabilities
> of a device is one-bit field definition, it has 64 different values at
> most.
> 
> Nowdays the receiving queue of NIC has rich features not just checksum
> offload, like it can extract the network protocol header fields to its
> RX descriptors for quickly handling. But this kind of feature is not so
> common, and it is hardware related. Normally, this can be done through
> rte_devargs driver parameters, but the scope is per device. This is not
> so nice for per queue design.
> 
> The per queue API 'rte_eth_rx_queue_setup' and data structure 'struct
> rte_eth_rxconf' are stable now, and be common for all PMDs. For keeping
> the ethdev API & ABI compatibility, and the application can make good
> use of the NIC's specific features, reserving the most-significant bits
> of RX offload seems an compromise method.
> 
> Then the PMDs redefine these bits as they want, all PMDs share the same
> bit positions and expose their new definitions with the header file.
> 
> The experimental reserved bits number is 6 currently. Tt can be one-bit
> for each features up to the the maximum number 6. It can also be some
> bits encoding: e.g, 6 bits can stand for 63 maximum number of features.
> 
> We call these reserved bits as DEV_RX_OFFLOAD_PMD_SCRATCH. And the left
> unused bits number is : 64 - 19 (currently defined) - 6 (PMD scartch) =
> 39.
> 
> This is not so nice for applications, they need to check PMD's driver
> name for lookuping their DEV_RX_OFFLOAD_PMD_SCRATCH definitions. But it
> is good for the applications to make use of the hardware compatibility.
> 
> Signed-off-by: Haiyue Wang <haiyue.wang@intel.com>
> ---

Anything that is per device type is useless for a generic application.
The goal of the DPDK should be to provide a high performance platform
that works for many device types. Too often, I see patches from hardware
vendors that are just "we can enable are cool proprietary hardware
feature in DPDK". This would just encourage that bad practice.