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.
