From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) by dpdk.org (Postfix) with ESMTP id 245811F3 for ; Fri, 16 Aug 2013 01:30:47 +0200 (CEST) Received: by mail-pd0-f173.google.com with SMTP id p10so1404807pdj.4 for ; Thu, 15 Aug 2013 16:31:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=hEU9XvTWv1e93Qgz+iIYPGExmJ7CIB3INmM9vhglQXU=; b=lnyLreLKVeaPCO1/QdniSWNT5MEN1wkHx9whgXL+uc/s+aStD0tASXOevpkRJeIBnn zyddNsVYg1vuLufjkJ1h0FRB5mL8MNarABizH4cwH3WZzhmzy0Q07im2gxcUhXaKzwRd uN/EX/TrZGo/w6Gs3V35xJtiH/YWpvouB+eoGkpBOBN1dbdQy4qhp5KPwkDy5MUXCbtY oeOzb6/t8QbP+vXrdns14T2/XwhrXh9Q2ojgLrYAJRteaNErZG5YWgZgm4JqQ/BwdUP0 DWHnzgy/Kxh79yUG0ED4NiI6iJAUJGBTMatng7ph+tQ42sBze8Bl5TF+whC3sybdmPYr +a+g== X-Gm-Message-State: ALoCoQnTLMN6S0s3mDLS1Idzxa4pmi9ArLdjO0lVW2YxC2F8Ey13HpPxlhgTWfhykdjh9HxT0txY X-Received: by 10.68.76.101 with SMTP id j5mr18141868pbw.67.1376609476199; Thu, 15 Aug 2013 16:31:16 -0700 (PDT) Received: from nehalam.linuxnetplumber.net (static-50-53-69-237.bvtn.or.frontiernet.net. [50.53.69.237]) by mx.google.com with ESMTPSA id vu5sm2090002pab.10.2013.08.15.16.31.15 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 15 Aug 2013 16:31:15 -0700 (PDT) Date: Thu, 15 Aug 2013 16:31:12 -0700 From: Stephen Hemminger To: Marc Sune Message-ID: <20130815163112.3fa3d9f7@nehalam.linuxnetplumber.net> In-Reply-To: <520D52E8.9000407@bisdn.de> References: <520B4641.2030802@bisdn.de> <008101ce9959$e4959370$adc0ba50$@126.com> <20130815075704.33261119@nehalam.linuxnetplumber.net> <520D52E8.9000407@bisdn.de> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; 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: Re: [dpdk-dev] =?gb2312?b?tPC4tDogUG9ydC1pZHMgYW5kIE5JQyBmZWF0dXJl?= =?gb2312?b?cw==?= 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: Thu, 15 Aug 2013 23:30:49 -0000 On Fri, 16 Aug 2013 00:15:04 +0200 Marc Sune wrote: > Dear Stephen, > > 1) The problem is that, if the interfaces are binded to the IGB_UIO > driver *before* the DPDK-based application is started, there is no way, > as far as I've seen, to get such information. Of course, you cannot use > anymore ethtool or whatever to get at least the speeds that the card is > supporting. Btw, I don't need them, but offloads would probably be also > quite useful. So in general all the "features" or "capabilities" > supported by the NIC. The hack for now is doing: struct rte_eth_dev_info dev_info; rte_eth_dev_info_get(portid, &dev_info); if (strncmp(dev_info.driver_name, "rte_ixgbe", 9) == 0) /* do stuff for 10G */ else /* do stuff for 1G */ Obviously, the driver_name approach could be generalized to a lookup table. But it really won't scale when many more drivers are added. Also since speed is negotiable, code should really wait till link is up to look at link speed and decide from that. Since device is totally owned by user driver at this point, it is perfectly possible to extend the existing drivers to do more PHY interaction to query/set speed and duplex. The current code just assumes autonegotiation. Since the Intel drivers are based off of BSD source there still is unused code to do this (I think).