From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by dpdk.org (Postfix) with ESMTP id 6DEB568CB for ; Fri, 11 Apr 2014 19:56:27 +0200 (CEST) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 11 Apr 2014 10:58:03 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,843,1389772800"; d="scan'208";a="417904805" Received: from orsmsx103.amr.corp.intel.com ([10.22.225.130]) by azsmga001.ch.intel.com with ESMTP; 11 Apr 2014 10:57:43 -0700 Received: from orsmsx102.amr.corp.intel.com ([169.254.1.111]) by ORSMSX103.amr.corp.intel.com ([169.254.2.174]) with mapi id 14.03.0123.003; Fri, 11 Apr 2014 10:57:43 -0700 From: "Venkatesan, Venky" To: Neil Horman , Stephen Hemminger Thread-Topic: [dpdk-dev] Poor device abstraction's Thread-Index: AQHPVa5G9IGGfrV6EEiniSlJbbKBvJsMsdrw Date: Fri, 11 Apr 2014 17:57:41 +0000 Message-ID: <1FD9B82B8BF2CF418D9A1000154491D97406521E@ORSMSX102.amr.corp.intel.com> References: <20140409183952.GA16493@hmsreliant.think-freely.org> <20140411103331.060c8a7d@nehalam.linuxnetplumber.net> <20140411174727.GF911@hmsreliant.think-freely.org> In-Reply-To: <20140411174727.GF911@hmsreliant.think-freely.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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:56:28 -0000 Agree that the patch sets are a step towards fixing that, but there is a lo= t more to be done on this. Could we start discussion on what the "ideal" ab= straction 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.=20 -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=20 > abstract the properties of the Ethernet device. The existing=20 > parameters match those of Intel's Ethernet hardware but not much else.=20 > It also makes it hard to write generic applications. If the=20 > application has to query the device driver name string and insert=20 > different parameters for igb, igbvf, ixgbe and vmxnet3 then the API was d= esigned wrong. >=20 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 reso= urce > not the number of packets. An application really wants to say "you ma= y buffer > up to 100us of packets" not have to guess what the underlying driver = does. >=20 > * the rthresh/wthresh/pthresh are PCI device artifacts and correct valu= e 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 l= atency". >=20 > These seems like issues of a transition from a cool toy to talk to=20 > Intel hardware to a useful application infrastructure. >=20 > That is why I would hate to see the existing Intel device centric API fro= zen. >=20