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 7C75CA057B; Thu, 2 Apr 2020 14:54:15 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5C8461BE95; Thu, 2 Apr 2020 14:54:15 +0200 (CEST) Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com [210.118.77.12]) by dpdk.org (Postfix) with ESMTP id AD1CE2BCE for ; Thu, 2 Apr 2020 14:54:13 +0200 (CEST) Received: from eucas1p1.samsung.com (unknown [182.198.249.206]) by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id 20200402125413euoutp02dd942d0d4a35020345b3c6cb15e74a15~CAdmoeKL20720407204euoutp02W for ; Thu, 2 Apr 2020 12:54:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20200402125413euoutp02dd942d0d4a35020345b3c6cb15e74a15~CAdmoeKL20720407204euoutp02W DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1585832053; bh=B2YiTCKGBQj6aDi5wQTaKKzByBBisM9e99/+KsXgUKQ=; h=Subject:To:Cc:From:Date:In-Reply-To:References:From; b=baWPhKD39P6hjbSuyTld7U4R3vULaYkdeVaSbCoFVTWucgvOP9iBrh13I7Kt1afiF kbKVrVjIE8jdLQN5PzIJIO0idjkyGIRDcMxg0EVx+feBT5tF0/19Ty3BaRIi6MWEHz 72G1aum2y0cYdvywNn3sm3SmszKoNeEV4z75pQcQ= Received: from eusmges2new.samsung.com (unknown [203.254.199.244]) by eucas1p2.samsung.com (KnoxPortal) with ESMTP id 20200402125412eucas1p2fc70fc656784dcf2e40699396b2bd5ce~CAdmf5FYG0785707857eucas1p2H; Thu, 2 Apr 2020 12:54:12 +0000 (GMT) Received: from eucas1p2.samsung.com ( [182.198.249.207]) by eusmges2new.samsung.com (EUCPMTA) with SMTP id 02.F0.60679.470E58E5; Thu, 2 Apr 2020 13:54:12 +0100 (BST) Received: from eusmtrp1.samsung.com (unknown [182.198.249.138]) by eucas1p2.samsung.com (KnoxPortal) with ESMTPA id 20200402125412eucas1p25befc7a805047bd038a8f436d1d050ea~CAdmMRwGO0786607866eucas1p2L; Thu, 2 Apr 2020 12:54:12 +0000 (GMT) Received: from eusmgms1.samsung.com (unknown [182.198.249.179]) by eusmtrp1.samsung.com (KnoxPortal) with ESMTP id 20200402125412eusmtrp1561aad1bb2517a2f4654c55429b9cd69~CAdmLkAVb2754727547eusmtrp1q; Thu, 2 Apr 2020 12:54:12 +0000 (GMT) X-AuditID: cbfec7f4-0cbff7000001ed07-9f-5e85e07416b8 Received: from eusmtip2.samsung.com ( [203.254.199.222]) by eusmgms1.samsung.com (EUCPMTA) with SMTP id 7C.2E.08375.470E58E5; Thu, 2 Apr 2020 13:54:12 +0100 (BST) Received: from [106.109.129.29] (unknown [106.109.129.29]) by eusmtip2.samsung.com (KnoxPortal) with ESMTPA id 20200402125411eusmtip265247433fd1458db344d8bb8081fa426~CAdlbneYa3106231062eusmtip2X; Thu, 2 Apr 2020 12:54:11 +0000 (GMT) To: =?UTF-8?Q?Morten_Br=c3=b8rup?= , Thomas Monjalon , Ferruh Yigit , Andrew Rybchenko Cc: dev@dpdk.org, Matan Azrad , "Benoit Ganne (bganne)" , maxime.coquelin@redhat.com, tiwei.bie@intel.com, amorenoz@redhat.com, zhihong.wang@intel.com, xiaolong.ye@intel.com From: Ivan Dyukov Message-ID: Date: Thu, 2 Apr 2020 15:54:11 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C60F2E@smartserver.smartshare.dk> Content-Transfer-Encoding: 8bit Content-Language: ru-RU X-Brightmail-Tracker: H4sIAAAAAAAAA02SeUgUYRjG+2Zmd8fNqXE196UEYQnKILusJgorKBjCjn+KELUmHY9yN9tV uyBsRbG1wsx2bUOzwwOvrj3MzNSVNV1SUiwtz7LA0uwSzDN3x8j/fu/zvg/v+3x8JC5rEy0l Y1TxvFrFxSrEUsJi/9OyOr4vJWxtavpmJqWij2D6srrFzNjHq2Lm208rxnQ9d0iYgpwcnLFf qiKYq+PtiPnZ95JgzEkzGDM5tJF58joT2+HOZk08ErHjefki9l7VIMZ+Ntgw1t6pl7Aj1e1i tulDOs6WDIyJD5DB0m0RfGxMIq9eE3hUGt2SOSqKK/U+M9qrw5LQA5kOuZFAB0CpqZ7QISkp o4sQ1FhuI6H4jaArt0ssFL8Q3M9qQf8shcNlLpbRhQgMqRHC0AiCO20GsbPhSR+E7nqty+1F P0eQ55jBnQVOv0UwlG9z2cX0SnCk5WJOpuhA0OqtEicT9HIw2J8STl5CHwa9dRoJMx7QeHPA pbvR++HGn88uxmlfSDbfwgWWw3drrWsz0D8k8ClzEhfu3gUdra0SgT3hS4Npjn3Acf0yIfB5 qNINSwRzGoLRJPNc6O1g+to82yBnN/jBg8o1grwTLE8eipwy0IugY9hDuGERZFoMuCBTkJY6 99gKqGlsnZMBpibcM5DCOC+YcV4Y47wwxv9r8xBRjOR8gkYZxWvWq/jT/hpOqUlQRfmHn1Q+ RrNfzTHd8LsCVU4eq0M0iRTu1ILalDCZiEvUnFXWISBxhRe1M3tWoiK4s+d49ckj6oRYXlOH lpGEQk5tuDsYKqOjuHj+BM/H8ep/XYx0W5qEOKPcFGkO/PZ+we6sFC60Oqcg2LbnlKdOb372 JuTCocXa8ib5xYjXPskhReppNd5LUI/vsgeDoi9g4ZHZhvKJd6+CLT22ffqewY3uxzddLqF+ Ba3YuvDEyoz0xVMxfh5b8vopbTNVFnfFV2fuLHF74TEZYNxrP3UtVt/t3W8tfqkgNNHculW4 WsP9BYQwuUdmAwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOIsWRmVeSWpSXmKPExsVy+t/xe7olD1rjDB4cVLRo3fGAxeLBlLts Fj8e97FZvPu0ncnizt7T7BbL5s5ltjjWuYfFou/XVUaLTw9OsFhsbfjPZPHnjanF5ouTmBx4 PKb83sjq8WvBUlaPxXteMnk8m36YyePYzWnsHu/3XWXzOPWom9lj9ZMfbAEcUXo2RfmlJakK GfnFJbZK0YYWRnqGlhZ6RiaWeobG5rFWRqZK+nY2Kak5mWWpRfp2CXoZ5yd9ZS1YI1bx9X4X UwPjeqEuRk4OCQETieVv1zJ2MXJxCAksZZR49W4WWxcjB1BCQuL1E2aIGmGJP9e62CBq3jJK TP+9ESwhLBAqcfdIE1hCRGAvo8Syhl1gk5gFbjJK7L7SCjW2iUni1a2NrCAtbAIaEqc75jGB 2LwCdhJN07azg9gsAioS04/tZAGxRQUiJB5PbGeEqBGUODnzCVicU8BfYurPZ2A2s4CZxLzN D5khbHmJ5q2zoWxxiQ/bD7JNYBSahaR9FpKWWUhaZiFpWcDIsopRJLW0ODc9t9hQrzgxt7g0 L10vOT93EyMwkrcd+7l5B+OljcGHGAU4GJV4eBkOtsYJsSaWFVfmHmKU4GBWEuF1nAEU4k1J rKxKLcqPLyrNSS0+xGgK9NxEZinR5HxgkskriTc0NTS3sDQ0NzY3NrNQEuftEDgYIySQnliS mp2aWpBaBNPHxMEp1cA4/+ypqcW700x/rmOe+PlkeF3p5I2K9ra5ac8KZ/g9XdIizLujTuAv y6f1hpKtJu034yud0osXV82JzhErl3u6YPE7nRe2G58Guy7Le+kVUWz5R2jlaYY5EUavCucF Ld88rfFeqInY7+1RTcH9yvL9WwsVLVru5PUuyTqyUfLZHnujfbZlhtFKLMUZiYZazEXFiQCO hfjP+gIAAA== X-CMS-MailID: 20200402125412eucas1p25befc7a805047bd038a8f436d1d050ea X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20200401100845eucas1p221563f5cce853c8c5c9c65ced19454fa X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20200401100845eucas1p221563f5cce853c8c5c9c65ced19454fa References: <98CBD80474FA8B44BF855DF32C47DC35C60F2D@smartserver.smartshare.dk> <2254486.aKNjEaI27c@xps> <98CBD80474FA8B44BF855DF32C47DC35C60F2E@smartserver.smartshare.dk> 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" 01.04.2020 13:06, Morten Brørup пишет: >> 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ørup: >>> Thomas, Ferruh, Andrew (Ethernet API Maintainers), >>> >>> A command line option was recently added to set which speed a vNIC >> 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? > It is a patch for the virtio driver: > https://protect2.fireeye.com/url?k=e37beb37-beabe3df-e37a6078-000babff32e3-4aaaa0986ed7ec57&u=http://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. > >>> However, I suspect that this workaround rarely reflects the physical >> truth, and suggest that the application should handle it instead. >> >> I don't understand why we need to define some speed for virtual >> devices. >> >>> In other words... Instead of faking it in the virtual Ethernet >> drivers, I suggest that rte_ethdev.h defines a special speed value for >> vNICs which really don't have a physical link speed: >>> #define ETH_SPEED_NUM_NONE 0 /**< Not defined */ >> 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. >> >>> +#define ETH_SPEED_NUM_UNKNOWN 1 /**< Unknown (virtual device) >> */ >> >> 1 means 1 Mbps >> >>> #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 >> (virtual device) */ >> >> Yes I agree with extending the comment for NONE. >> >>> The special value could also be used in cases like this: >>> >> https://protect2.fireeye.com/url?k=6154668d-3c846e65-6155edc2-000babff32e3-bf63d034253cac80&u=http://inbox.dpdk.org/dev/AM0PR0502MB401907ADE7CEA27DC642DF35D2CB0@AM0P >> R0502MB4019.eurprd05.prod.outlook.com/T/#t >> >> Yes, if speed is unknown, it should be reported as 0. > So the next related question is: Should a vNIC be allowed to report a fake speed if it does not know that the underlying hardware actually provides this speed? >