Hi > -----Original Message----- > From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: Friday, June 21, 2019 02:36 > To: Wang, Haiyue <haiyue.w...@intel.com> > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [RFC] ethdev: reserve the RX offload most-significant > bits for PMD scartch > > 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.
Understand the DPDK's dream. :) This patch wants to make the bad application and bad vender to use the DPDK's generic high performance platform features, plus some bad practice like doing special hardware optimization. Very appreciate your feedback. The PMDs should limit their desires. ;-)
