[dpdk-dev] DPDK and HW offloads

[Zhang, Helin]

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Saturday, March 19, 2016 2:01 AM
> To: Stephen Hemminger <stephen at networkplumber.org>
> Cc: Zhang, Helin <helin.zhang at intel.com>; dev at dpdk.org
> Subject: Re: DPDK and HW offloads
> 
> 2016-03-18 10:16, Stephen Hemminger:
> > As I look at how the ethernet device interface in DPDK has exploded in
> > complexity;
> 
> Yes I would like to start addressing this complexity in 16.07.
> 
> > it makes life very hard for end users.  The goal has been to enable
> > all the cool hardware features, but it has put blinders on the driver
> > devlopers; they are ignoring the fact that real applications can't just work on
> one kind of hardware.
> 
> +1
Agree that DPDK needs to add common APIs from application's point of view.

> 
> > The DPDK is doing a terrible job at providing abstractions.  There
> > needs to be a real generic set of operations, and every hardware offload
> feature must:
> >   * have a clear well defined API
> 
> +1
> 
> >   * if feature is not available in software, then the DPDK must provide
> >     a software equivalent feature.
> 
> I'm not against this idea. Looking for more opinions.
> 
> >   * any difference in API must be hidden from application.
> >   * no compile config options about offload.
> >   * tests and documentation must work for both hw and sw version
> >
> > 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.