From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id D3528A0562; Thu, 2 Apr 2020 17:30:08 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id EB6B91B91B; Thu, 2 Apr 2020 17:30:07 +0200 (CEST) Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com [209.85.210.177]) by dpdk.org (Postfix) with ESMTP id 663312BCE for ; Thu, 2 Apr 2020 17:30:06 +0200 (CEST) Received: by mail-pf1-f177.google.com with SMTP id u65so1918555pfb.4 for ; Thu, 02 Apr 2020 08:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=R6RsxOWqxfOoYeh79Nvr9e8KaFugZnWyWHU8kIVFJrI=; b=HDXrAXUnPFaTu8ED0fLFLAZduuFmesaVStumdySiGMnPaUlEuFArVWooiEtLavcfJA nLkaOuAEkLWM0Tg1yD/WlHPjGkoc7r+xmDSsULsIOj4RxW1NfZQ2MsFltPK5OTreKcDF Z0LMGJv8wpk8rqqhxVL87rKiYXOv76aek0gkp47Zl9RZO9Uj/2d/UxDtxl0ZKWry4oUe x5rfVf9pCrEDgL9g9vDCJZF/Lg/GLcJQpLPHnxsAAkI3O3wViS5ppcJeM0FbkGQM6jeL l+TpqJwyc/gAkoor5dTPzo9YBJc6wIztE3hBFqs9YzyNRJZs5rFKGFhVDI3NgJj9bc28 7TjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=R6RsxOWqxfOoYeh79Nvr9e8KaFugZnWyWHU8kIVFJrI=; b=I6DR7mpRefPz97l2Kgga7lKjfD1pYc13pGvXd4cOQ3QKyGiUE2zwq0rKdNZ77WOzXv 5ff6VZyzNftB/Wlh4UKN6WiJawL5/e38COhMFbdroa4semNgOm3/YC10SiJhYgwShSp2 xEOSVtcf4Y7WkuXn/F1q8lofJyo5DEmgAGLkFj+4ON3dEMeNqueT/Ca5xrpBVVFmBdUJ oInZF/6vjB8mMdKMWTd227P45u2NstsmRBvoqKUGsmZ8GXetrm5gvMZ3FMMrxA2lD9bK Gd1SaHgaSIwnGHVrAciOiTXQdaEfu/twWMFBQgXnUx2ma3VawU0ykpHYJQmqizx0a+os Nq8A== X-Gm-Message-State: AGi0PuZYe/TbJGYfHtP1ZUDn8t8TKl2Tk0Oe3xtL6pqDjCy21KUgVE6G opaOXYjSgRPLdlyMYSSo7+GmTw== X-Google-Smtp-Source: APiQypK8Oush8z/vuCjLnJTgf7VuQ64r4eWaE4RrN6Tfk51ngXD30kNnQntF8DaBDr++26QgqchPOw== X-Received: by 2002:a62:18cf:: with SMTP id 198mr3724738pfy.277.1585841405411; Thu, 02 Apr 2020 08:30:05 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id s14sm3685383pgl.4.2020.04.02.08.30.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Apr 2020 08:30:05 -0700 (PDT) Date: Thu, 2 Apr 2020 08:29:56 -0700 From: Stephen Hemminger To: Morten =?UTF-8?B?QnLDuHJ1cA==?= Cc: "Ivan Dyukov" , "Thomas Monjalon" , "Ferruh Yigit" , "Andrew Rybchenko" , , "Matan Azrad" , "Benoit Ganne (bganne)" , , , , , Message-ID: <20200402082956.7ce3b7d3@hermes.lan> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C60F3A@smartserver.smartshare.dk> References: <98CBD80474FA8B44BF855DF32C47DC35C60F2D@smartserver.smartshare.dk> <2254486.aKNjEaI27c@xps> <98CBD80474FA8B44BF855DF32C47DC35C60F2E@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35C60F3A@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, 2 Apr 2020 15:50:00 +0200 Morten Br=C3=B8rup wrote: > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ivan Dyukov > > Sent: Thursday, April 2, 2020 2:54 PM > >=20 > > 01.04.2020 13:06, Morten Br=C3=B8rup =D0=BF=D0=B8=D1=88=D0=B5=D1=82: =20 > > >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon > > >> Sent: Wednesday, April 1, 2020 11:54 AM > > >> > > >> 01/04/2020 11:33, Morten Br=C3=B8rup: =20 > > >>> Thomas, Ferruh, Andrew (Ethernet API Maintainers), > > >>> > > >>> A command line option was recently added to set which speed a vNIC = =20 > > >> reports when the link is up. This makes sense for Spanning Tree and > > >> other protocols which depend on link speed. > > >> > > >> Please could you reference the patch? =20 > > > It is a patch for the virtio driver: > > > https://protect2.fireeye.com/url?k=3De37beb37-beabe3df-e37a6078- =20 > > 000babff32e3- > > 4aaaa0986ed7ec57&u=3Dhttp://inbox.dpdk.org/dev/20191212085012.9170-1- > > i.dyukov@samsung.com/T/#m052f90ea8c559406aeaefaea1fc24ed9bb573788 > > This patch is related to similar work in qemu & kernel virtio driver. > > Please see > > https://lists.oasis-open.org/archives/virtio- > > comment/201911/msg00058.html. > > These changes have been implemented and released in kernel and qemu. > > speed is negotiated from qemu and then user may change the speed of > > virtio device using ethtool utility. I have added similiar patchset for > > pmd driver which do the same but for changing speed I used devargs > > instead of ethtool. =20 >=20 > Very interesting link, indeed! >=20 > It gives the virtio driver the possibility to expose a specific speed in = Mbit/s, which I assume - when used correctly - should reflect the speed of = the underlying hardware. So it could be 20 Gbit/s for a link aggregate (in = IEEE 802.3 Ethernet terminology; "bond" in Linux terminology) of two 10G po= rts. >=20 > It also provides a special value for unknown speed. >=20 > > > =20 > > >>> However, I suspect that this workaround rarely reflects the =20 > > physical =20 > > >> truth, and suggest that the application should handle it instead. > > >> > > >> I don't understand why we need to define some speed for virtual > > >> devices. > > >> =20 > > >>> In other words... Instead of faking it in the virtual Ethernet =20 > > >> drivers, I suggest that rte_ethdev.h defines a special speed value = =20 > > for =20 > > >> vNICs which really don't have a physical link speed: =20 > > >>> #define ETH_SPEED_NUM_NONE 0 /**< Not defined */ =20 > > >> The only issue with this constant is the lack of RTE_ prefix :-) > > >> Otherwise I think "0 - NONE - not defined" fits well with virtual > > >> device case. > > >> =20 > > >>> +#define ETH_SPEED_NUM_UNKNOWN 1 /**< Unknown (virtual device)= =20 > > >> */ > > >> > > >> 1 means 1 Mbps > > >> =20 > > >>> #define ETH_SPEED_NUM_10M 10 /**< 10 Mbps */ > > >>> > > >>> Alternatively, we could expand the meaning of ETH_SPEED_NUM_NONE: > > >>> > > >>> -#define ETH_SPEED_NUM_NONE 0 /**< Not defined */ > > >>> +#define ETH_SPEED_NUM_NONE 0 /**< Not defined or unknown = =20 > > >> (virtual device) */ > > >> > > >> Yes I agree with extending the comment for NONE. > > >> =20 > > >>> The special value could also be used in cases like this: > > >>> =20 > > >> https://protect2.fireeye.com/url?k=3D6154668d-3c846e65-6155edc2- =20 > > 000babff32e3- > > bf63d034253cac80&u=3Dhttp://inbox.dpdk.org/dev/AM0PR0502MB401907ADE7CEA= 27 > > DC642DF35D2CB0@AM0P =20 > > >> R0502MB4019.eurprd05.prod.outlook.com/T/#t > > >> > > >> Yes, if speed is unknown, it should be reported as 0. =20 >=20 > Could the DPDK vNIC PMDs be updated accordingly? At least the virtio driv= er... >=20 > > > So the next related question is: Should a vNIC be allowed to report a= =20 > > fake speed if it does not know that the underlying hardware actually > > provides this speed? =20 >=20 > Your link to the Kernel/QEMU patch answers this question: Yes, because we= assume it reflects the underlying speed. >=20 >=20 The problem is that if devices start returning this new value, then it is an API breakage for existing applications that look at speed.