From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by dpdk.org (Postfix) with ESMTP id 81C335902 for ; Fri, 11 Apr 2014 19:31:57 +0200 (CEST) Received: by mail-pa0-f50.google.com with SMTP id kq14so5677592pab.37 for ; Fri, 11 Apr 2014 10:33:34 -0700 (PDT) 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-type:content-transfer-encoding; bh=rh4eYdt6U7TDxKxQSR7QAUP4HO236a/RmaBQzErQNUo=; b=KQLOW4D0FZAvQO8qm29dZxxUgcl8Iz/Tf0Ea3moc38affwFzFmNXYlbxqggh7zK9G7 xy12H1UJjDmXOvqx+vmNNA3B1Bw7tLoc4USmVCk745iHMSqXpbg7t+TBrYgRJNtg4vIA C5D9HRA8a4vs8GmjPC+3JALC+xzC5dWDunYQ1eqBqfMv9z0ZgftkQw3s0/hwsc/BBKkp dJ4d5qXEsx81npubjg8cGgVnY9CKPHKGmvekTPCyPImeUT5AewtUwNREgDtA+HyO8qDQ IEvqJtC3U/gRx3sSX3S/3Yc7si+qGibwcqX9SRIjpJjYbvxprDEPzRxYrFUyQaz8+ZPv tr3Q== X-Gm-Message-State: ALoCoQlQpNjKPAr+9yRtN0Q2R3MjwWln/2Vf0+3qhb8wNldc11bn5kI60u3yxZu2C+MGugfhDvL9 X-Received: by 10.68.143.34 with SMTP id sb2mr28542343pbb.135.1397237614784; Fri, 11 Apr 2014 10:33:34 -0700 (PDT) Received: from nehalam.linuxnetplumber.net (static-50-53-83-51.bvtn.or.frontiernet.net. [50.53.83.51]) by mx.google.com with ESMTPSA id ir10sm16894376pbc.59.2014.04.11.10.33.34 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 11 Apr 2014 10:33:34 -0700 (PDT) Date: Fri, 11 Apr 2014 10:33:31 -0700 From: Stephen Hemminger To: Neil Horman Message-ID: <20140411103331.060c8a7d@nehalam.linuxnetplumber.net> In-Reply-To: <20140409183952.GA16493@hmsreliant.think-freely.org> References: <20140409183952.GA16493@hmsreliant.think-freely.org> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: [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:31:57 -0000 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. 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.