From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 1B755A0562; Fri, 3 Apr 2020 13:01:39 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3C4DE1C12F; Fri, 3 Apr 2020 13:01:38 +0200 (CEST) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) by dpdk.org (Postfix) with ESMTP id 32B161C129 for <dev@dpdk.org>; Fri, 3 Apr 2020 13:01:36 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 80D895802B4; Fri, 3 Apr 2020 07:01:34 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Fri, 03 Apr 2020 07:01:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=nBd87FIEVoQ5/r5XFAUqfXEqaQQ7Mcz+aU7tZUzCUFo=; b=KxhkFjZQwyVe 9YzLmlytPf+5/m2xYPKCHx1qspsHiGgB0GWUQ/YZ99OkAStO/E0HsF7GRYpbNLQF xC0cBKoXt9RYC7nL/KxzeyPF3WkcTIspNoZXYtHLt0lMSLRLWFDoObeoufpmX9+z 5SyZC5ptGXFgdvvOT50Bm16tPaZHpQo= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=nBd87FIEVoQ5/r5XFAUqfXEqaQQ7Mcz+aU7tZUzCU Fo=; b=npN1hGcFhHlJ5uuz8sLrh6yzFYsP8jnPqFrAl8OTBbqr8YybThQXh7CJu TeK0lSOLowDDAjY/uC5a5x4T400/dDj6mTumDsJJN+nyznXqL8FXojCsGFPSHR5O nzP4KVUtk9YnMJDS7RgI3jucvObeJAHmAPcH1ix4t5VqT+Wwlod1jKrM4gad46OD xsQJxFL8O2h85eJeVb8bHxiXhlGDVS8XgXjnfWJO4dEsnmoSwgZyBDYnIZy+EI4S DrF5PLuHQwtYRyGk2gbDk532JaJvGzyukfWqbiwdKct2w9cMiD57c7shh3LwGC+U Gh4vePbcJCModvaon4JAos3WxL7Kw== X-ME-Sender: <xms:jReHXg_iHKvv1xFDY-Rfybusmun2oKiZC1v72MlSUirst0nDEOo3hw> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrtdeigdefiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: <xmx:jReHXq--BzVomVCmvAc8QLRFaFO8bLaqEfuzK1Ocio65yq3GOFqmtQ> <xmx:jReHXoRGNQA-zteAkg5BC9mA1Q5KRbwQb4HMaCWBCCiRJ4Jo28l4lQ> <xmx:jReHXmcMafyYo1FNpgaD19cILTx98t67hp1ZKQgWaFhvym2kkOLhlA> <xmx:jheHXkfcL2y2BXvpMGt5tdsCShi1XxW_V_upeCgDskcBC9NpTw588g> Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 24098306CF6C; Fri, 3 Apr 2020 07:01:32 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: Ivan Dyukov <i.dyukov@samsung.com>, Morten =?ISO-8859-1?Q?Br=F8rup?= <mb@smartsharesystems.com> Cc: Ferruh Yigit <ferruh.yigit@intel.com>, Andrew Rybchenko <arybchenko@solarflare.com>, dev@dpdk.org, Matan Azrad <matan@mellanox.com>, "Benoit Ganne (bganne)" <bganne@cisco.com>, maxime.coquelin@redhat.com, Vladimir Kuramshin <v.kuramshin@samsung.com>, amorenoz@redhat.com, zhihong.wang@intel.com, xiaolong.ye@intel.com, Stephen Hemminger <stephen@networkplumber.org> Date: Fri, 03 Apr 2020 13:01:31 +0200 Message-ID: <4957996.Zugxlq0yvN@xps> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C60F3C@smartserver.smartshare.dk> References: <98CBD80474FA8B44BF855DF32C47DC35C60F2D@smartserver.smartshare.dk> <c29ec4a4-cd75-0d47-cdc7-54acf8c928a2@samsung.com> <98CBD80474FA8B44BF855DF32C47DC35C60F3C@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [RFC] ethdev: use special speed for virtual Ethernetdevices X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> 03/04/2020 11:45, Morten Br=C3=B8rup: > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ivan Dyukov > > Sent: Friday, April 3, 2020 10:06 AM > >=20 > > 02.04.2020 23:58, Thomas Monjalon =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > > 02/04/2020 22:41, Ivan Dyukov: > > >> 02.04.2020 16:50, Morten Br=C3=B8rup =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > >>>>>> Yes, if speed is unknown, it should be reported as 0. > > >>> Could the DPDK vNIC PMDs be updated accordingly? At least the > > virtio driver... > > >> Current version of dpdk code on master always returns 10G speed for > > >> virtio device and many application rely on it. e.g. pktgen. If we'll > > >> change it, we break the apps. > > > I am OK with breaking such strange assumption. > > > I can understand the need for specifying the underlying hardware > > speed > > > through virtio driver. But hardcoded 10G... no! > > > > > > > > > > > OK. I'll redefine it to 0xffffffff, like in kernel virtio. > >=20 >=20 > Thomas, you were opposed to using 1 as the special value for "unknown", a= s it is likely interpreted as 1 Mbps instead, and I agree with your reasoni= ng on that. >=20 > Since using an extremely large value is as close to infinity we can get, = Ivan's suggested value makes sense to me instead: >=20 > +#define ETH_SPEED_NUM_UNKNOWN 0xffffffff /**< Unknown */ >=20 > In theory, it also addresses Stephen's concern about breaking the ABI for= existing applications that look at speed. They will get a non-zero speed, = which is not a randomly chosen fake 10G speed; so I consider it an improvem= ent. > Although in reality, such applications may still break if they are unable= to handle the extreme speed of 4.3 Pbps. >=20 > I considered "Unlimited" instead of "Unknown", but Unlimited is not reall= y correct, so I settled with Unknown. Yes it makes sense. The only drawback is that the information "speed is accurate" will be checked against two constants: ETH_SPEED_NUM_NONE or ETH_SPEED_NUM_UNKNOWN It can be mitigated with a function though.