Re: DPDK and HW offloads

[Stephen Hemminger <stephen@networkplumber.org>]

On Tue, 22 Mar 2016 07:19:01 -0500
Jay Rolette <rolette@infinite.io> wrote:

> On Tue, Mar 22, 2016 at 5:19 AM, Bruce Richardson <
> bruce.richardson@intel.com> wrote:
> 
> > On Tue, Mar 22, 2016 at 05:50:28AM +0000, Qiu, Michael wrote:
> > >
> > > Why not to implement one simple API with variable arguments, just like
> > > syscall ioctl() does. And drivers implement it's specific hardware
> > > features with a feature bit param, and other needed variable arguments.
> > >
> > > Thanks,
> > > Michael
> >
> > A very much dislike that idea.
> > * It makes the code much harder to read as you have to closely examine all
> > the
> >   parameters to work out what a function call is actually meant to do.
> > * It makes it much harder to see that you have an implicit dependency on a
> >   specific device. Having to include a driver specific header file e.g.
> > i40e.h,
> >   and call a function named e.g. i40e_do_magic_stuff(), makes it pretty
> > explicit
> >   that you have a dependency on i40e-based hardware
> > * It prevents the compiler from doing type-checking on parameters and
> > informing
> >   you of little inconsistencies.
> >
> > For all these reasons, I prefer the device-specific functions option.
> > However,
> > at the same time, we also need to ensure we have a reasonable set of
> > generic
> > APIs so that the cases where users are forced to drop down to the
> > lower-level
> > device-specific primitives are reduced.
> >
> 
> +1

I prefer the OO model where there is a generic network interface that provides
a uniform set of features, and if a specific hw device provides a more efficient
implementation of a feature, that is hidden (inheritance?) such that there
is no difference API.

The DPDK has been hardware vendor driven up until this point.
But from a software point of view, it is more important to provide good API than
use DPDK as a hardware POC environment.