From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Subject: Re: DPDK and HW offloads
Date: Tue, 22 Mar 2016 23:11:17 +0530
Message-ID: <20160322174116.GA13074@localhost.localdomain>
References: <20160318101611.2df26ef6@xeon-e3> <10753400.05iPBPOT6f@xps13>
 <F35DEAC7BCE34641BA9FAC6BCA4A12E70A9CD70B@SHSMSX104.ccr.corp.intel.com>
 <29795767.yLuRT7a5hO@xps13> <20160321145249.GA16732@bricha3-MOBL3>
 <CAMFWN9=daa-aNdi3+xE=zPt2kndTwgZCZ1YbxnWXyJNpY42EjA@mail.gmail.com>
 <533710CFB86FA344BFBF2D6802E6028622F70D9D@SHSMSX101.ccr.corp.intel.com>
 <20160322101941.GB19268@bricha3-MOBL3>
 <CADNuJVrHqzsy_5-vj96RO_s5oC0zRnjnY+89ua3fVYp2TdpKOg@mail.gmail.com>
 <20160322101721.4e6775fe@xeon-e3>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: Jay Rolette <rolette@infinite.io>, Bruce Richardson
 <bruce.richardson@intel.com>, "Qiu, Michael" <michael.qiu@intel.com>, Kyle
 Larose <eomereadig@gmail.com>, Thomas Monjalon <thomas.monjalon@6wind.com>,
 "Zhang, Helin" <helin.zhang@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
To: Stephen Hemminger <stephen@networkplumber.org>
Return-path: <dev-bounces@dpdk.org>
Received: from na01-bn1-obe.outbound.protection.outlook.com
 (mail-bn1on0091.outbound.protection.outlook.com [157.56.110.91])
 by dpdk.org (Postfix) with ESMTP id 8FB7D2BE2
 for <dev@dpdk.org>; Tue, 22 Mar 2016 18:41:45 +0100 (CET)
Content-Disposition: inline
In-Reply-To: <20160322101721.4e6775fe@xeon-e3>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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