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 1B92068CB for ; Fri, 11 Apr 2014 19:58:07 +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 1WYfjk-0001hI-7v; Fri, 11 Apr 2014 13:59:40 -0400 Date: Fri, 11 Apr 2014 13:59:35 -0400 From: Neil Horman To: "Venkatesan, Venky" Message-ID: <20140411175935.GG911@hmsreliant.think-freely.org> References: <20140409183952.GA16493@hmsreliant.think-freely.org> <20140411103331.060c8a7d@nehalam.linuxnetplumber.net> <20140411174727.GF911@hmsreliant.think-freely.org> <1FD9B82B8BF2CF418D9A1000154491D97406521E@ORSMSX102.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1FD9B82B8BF2CF418D9A1000154491D97406521E@ORSMSX102.amr.corp.intel.com> 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:58:07 -0000 On Fri, Apr 11, 2014 at 05:57:41PM +0000, Venkatesan, Venky wrote: > Agree that the patch sets are a step towards fixing that, but there is a lot more to be done on this. Could we start discussion on what the "ideal" abstraction should be? I'd like to pool those into a formal proposal that we can discuss and drive through a series of patches to make that happen. Even semi-freezing anything prior to that would be premature. > Well, just to throw something out there, what about starting with the net_device structure in the kernel, and removing things that are unnecessecary? That might give us a good starting point to see what else is needed Neil > -Venky > > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Neil Horman > Sent: Friday, April 11, 2014 10:47 AM > To: Stephen Hemminger > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] Poor device abstraction's > > 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. > > >