From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 4FBF35961 for ; Fri, 11 Apr 2014 19:45:57 +0200 (CEST) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1WYfY0-0001et-BI; Fri, 11 Apr 2014 13:47:34 -0400 Date: Fri, 11 Apr 2014 13:47:27 -0400 From: Neil Horman To: Stephen Hemminger Message-ID: <20140411174727.GF911@hmsreliant.think-freely.org> References: <20140409183952.GA16493@hmsreliant.think-freely.org> <20140411103331.060c8a7d@nehalam.linuxnetplumber.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140411103331.060c8a7d@nehalam.linuxnetplumber.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: dev@dpdk.org Subject: Re: [dpdk-dev] Poor device abstraction's 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: Fri, 11 Apr 2014 17:45:57 -0000 On Fri, Apr 11, 2014 at 10:33:31AM -0700, Stephen Hemminger wrote: > One of my pet peeve's is that the device driver config does not abstract > the properties of the Ethernet device. The existing parameters match those > of Intel's Ethernet hardware but not much else. It also makes it hard > to write generic applications. If the application has to query the > device driver name string and insert different parameters for igb, igbvf, ixgbe > and vmxnet3 then the API was designed wrong. > I agree. I think the patches that recently got integrated from Olivier are a step toward fixing that, but theres some more work to be done. Neil > Specific examples: > * the "descriptors" argument to rx/tx is interpreted as a hardware resource > not the number of packets. An application really wants to say "you may buffer > up to 100us of packets" not have to guess what the underlying driver does. > > * the rthresh/wthresh/pthresh are PCI device artifacts and correct value is > different for each HW device shouldn't be exposed to application. The API > should be something like "device may burst up to N packets and/or T latency". > > These seems like issues of a transition from a cool toy to talk to Intel hardware > to a useful application infrastructure. > > That is why I would hate to see the existing Intel device centric API frozen. >