From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=P0Xsg+IdqRjlFYasiZgVdlrQY+KqGcoII8tgGooko2M=; b=y+/DuVz+F4/bz0v1L9GH6iKqJJe3rfLEQdLI+fjqIjfZi8gSkSyAdqFqrGiQrHhjgU rekj5bXAJvZH1T4XTQKC+V0y4sa7rixeu4/jYgIkzbekBAZZd6KnRO8ExE/WABchcxQM KjDvCYKtJlWRzL2EfMHXUD7/q8q/uZTjBXb/fBydj8j4GJ2jgwbnKXLu+rfF38mrlRl8 4TrKDQy2ZDlLMUMnrh2Yj3xvxoH+kbO0XB4GATENtAlxhTeecgyO/lvKuJiIxS25/DA2 HsmScmtZJeu3122VjrBfWoAKZbhMJ02qJg6v1GUSvmrBo3zkGzb2+GlO/IbcOBju6Gi0 C1Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=P0Xsg+IdqRjlFYasiZgVdlrQY+KqGcoII8tgGooko2M=; b=JsGPfTJoXfVo3Aia+lIFeegQzwghv/VDTjuvaqqy22bfCcNL5uQWnsqPmY/XCYb8H7 FDHiw1FXG5JKmNyUfdGBsbXaHCDxqTTLVXso9nq6QLNa4NDkBwraPLkEVfInnXcu4H97 Bm5K76LRCN+6yI3JEZW2YPnpPuRFvNIGZOihU9mv002bfiZ8pO8SSCy9yKCKJhGNiP5M nPcFXttqM4Ti8CVSbignabb+KnU8we+kd7Spy8VaS+ZA8FquJxnw6WdAGoqBThgzCZwh phsSBNOrjNYcxMqG1kpOfhfiE1rQPqwiLfAXJPOJtWmOfUoAmjaZxwV9ftZFdmhOef2N xZ7A== X-Gm-Message-State: AD7BkJJsMJVdaTf49z6IFnaIBuXCSG6+rwzALOBCAi3fr+KhDvvVaRYPQ+ziXYVXYGEwWQ== X-Received: by 10.98.86.77 with SMTP id k74mr54619580pfb.28.1458667025404; Tue, 22 Mar 2016 10:17:05 -0700 (PDT) Received: from xeon-e3 (static-50-53-65-230.bvtn.or.frontiernet.net. [50.53.65.230]) by smtp.gmail.com with ESMTPSA id q4sm49662000pfi.94.2016.03.22.10.17.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Mar 2016 10:17:05 -0700 (PDT) Date: Tue, 22 Mar 2016 10:17:21 -0700 From: Stephen Hemminger To: Jay Rolette Cc: Bruce Richardson , "Qiu, Michael" , Kyle Larose , Thomas Monjalon , "Zhang, Helin" , "dev@dpdk.org" Message-ID: <20160322101721.4e6775fe@xeon-e3> In-Reply-To: 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 Subject: Re: [dpdk-dev] DPDK and HW offloads X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 17:17:06 -0000 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.