Re: [dpdk-dev] DPDK and HW offloads

[Jerin Jacob <jerin.jacob@caviumnetworks.com>]

On Tue, Mar 22, 2016 at 10:17:21AM -0700, Stephen Hemminger wrote:
> 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.

+1