Not so frightening in real world for an application to be aware of its NICs: https://github.com/Juniper/contrail-vrouter/blob/master/dpdk/vr_dpdk_ethdev.c#L387
Yes, we need to avoid this kind of design. BR, Haiyue From: Andrew Rybchenko [mailto:arybche...@solarflare.com] Sent: Friday, June 21, 2019 02:30 To: Wang, Haiyue <haiyue.w...@intel.com>; dev@dpdk.org Cc: Yigit, Ferruh <ferruh.yi...@intel.com>; Thomas Monjalon <tho...@monjalon.net> Subject: Re: [dpdk-dev] [RFC] ethdev: reserve the RX offload most-significant bits for PMD scartch CC ethdev maintainers On 6/20/19 10:25 AM, Haiyue Wang 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><mailto:haiyue.w...@intel.com> I would say that it very bad for applications. It sounds like reserved bits in registers which have meaning in fact and sometimes different meaning. Of course, it is not that bad when rules are defined, but such kind of features tend to spread and clutter up interfaces. IMHO, the feature is really frightening.
