[dpdk-dev] DPDK and HW offloads

Thomas Monjalon thomas.monjalon at 6wind.com
Sun Mar 20 20:18:57 CET 2016


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.


More information about the dev mailing list