From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: DPDK and HW offloads Date: Tue, 22 Mar 2016 10:17:21 -0700 Message-ID: <20160322101721.4e6775fe@xeon-e3> References: <20160318101611.2df26ef6@xeon-e3> <10753400.05iPBPOT6f@xps13> <29795767.yLuRT7a5hO@xps13> <20160321145249.GA16732@bricha3-MOBL3> <533710CFB86FA344BFBF2D6802E6028622F70D9D@SHSMSX101.ccr.corp.intel.com> <20160322101941.GB19268@bricha3-MOBL3> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Bruce Richardson , "Qiu, Michael" , Kyle Larose , Thomas Monjalon , "Zhang, Helin" , "dev@dpdk.org" To: Jay Rolette Return-path: Received: from mail-pf0-f175.google.com (mail-pf0-f175.google.com [209.85.192.175]) by dpdk.org (Postfix) with ESMTP id 1AF042BB4 for ; Tue, 22 Mar 2016 18:17:06 +0100 (CET) Received: by mail-pf0-f175.google.com with SMTP id u190so320687176pfb.3 for ; Tue, 22 Mar 2016 10:17:06 -0700 (PDT) In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, 22 Mar 2016 07:19:01 -0500 Jay Rolette 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.