On Thu, 20 Jun 2019 15:25:52 +0800 Haiyue Wang <haiyue.w...@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.w...@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.
