On Sun, Mar 20, 2016 at 08:18:57PM +0100, Thomas Monjalon wrote: > 2016-03-20 14:17, Zhang, Helin: > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > 2016-03-18 10:16, Stephen Hemminger: > > > > Right now, all those offload features are pretty much unusable in a > > > > real product without lots and lots of extra codes and huge bug > > > > surface. It bothers me enough that I would recommend removing much of > > > > the > > > filter/offload/ptype stuff from DPDK! > > > > > > One of the biggest challenge is to think about a good filtering API. > > > The offloading has some interaction with the mbuf struct. > > > > > > I would like to suggest rewriting ethdev API by keeping it as is for some > > > time for > > > compatibility while creating a new one. What about the prefix > > > dpdk_netdev_ to > > > progressively replace rte_eth_dev? > > > > I totally agree with to add new and generic APIs for user applications. But > > I don't > > think we need to remove all current APIs. Generic APIs may not support all > > advanced > > hardware features, while specific APIs can. Why not support all? One > > generic APIs for > > common users, and others APIs for advanced users. > > Yes we cannot access to every features of a device through generic API. > Until now we were trying to add an ethdev API for every features even if it > is used by only one driver. > I think we should allow a direct access to the driver by the applications and > work on generic API only for common features.
Definite +1. I think that we need to start pushing driver-specific functionality to get exposed via a driver's header files. That allow users who want to extract the max functionality from a particular NIC to do so via those APIs calls, while not polluting the generic ethdev layer. On the other hand, I don't like the idea of dpdk_netdev. I think we can work within the existing rte_eth_dev framework. /Bruce
