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 DAAAFA0562; Thu, 2 Apr 2020 22:41:42 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 05E211C027; Thu, 2 Apr 2020 22:41:42 +0200 (CEST) Received: from mailout1.w1.samsung.com (mailout1.w1.samsung.com [210.118.77.11]) by dpdk.org (Postfix) with ESMTP id E18F01BFA6 for ; Thu, 2 Apr 2020 22:41:40 +0200 (CEST) Received: from eucas1p1.samsung.com (unknown [182.198.249.206]) by mailout1.w1.samsung.com (KnoxPortal) with ESMTP id 20200402204140euoutp01e448ce0ea6ea426eb80668b56765b35a~CG1vj-UDa2115621156euoutp011 for ; Thu, 2 Apr 2020 20:41:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.w1.samsung.com 20200402204140euoutp01e448ce0ea6ea426eb80668b56765b35a~CG1vj-UDa2115621156euoutp011 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1585860100; bh=JiyUWj54QCU4zUEVk6T3AGyxak5QX5Dbo/6l+9QLDSw=; h=Subject:To:Cc:From:Date:In-Reply-To:References:From; b=qNnNx78bzZ6+x5dqwJDN60NqpWa2D7RTsPBoB+LyDWkKzL/qE2rgVcC6sWYIFQI5u UM5LdxXUZ6VIZgptoUxwvgsaD8hhLZ+LgSmQDEufF7LZO30Ayvf8U059PXl3/D/Kzv +jOIcJndgNmU2yiiq5udf1vsTiyXDGfBQulqXhJ8= Received: from eusmges1new.samsung.com (unknown [203.254.199.242]) by eucas1p1.samsung.com (KnoxPortal) with ESMTP id 20200402204139eucas1p1eef7ebb86add5ad98a9f8cac29392d00~CG1uiw_E50557505575eucas1p1S; Thu, 2 Apr 2020 20:41:39 +0000 (GMT) Received: from eucas1p2.samsung.com ( [182.198.249.207]) by eusmges1new.samsung.com (EUCPMTA) with SMTP id D5.5C.61286.30E468E5; Thu, 2 Apr 2020 21:41:39 +0100 (BST) Received: from eusmtrp2.samsung.com (unknown [182.198.249.139]) by eucas1p1.samsung.com (KnoxPortal) with ESMTPA id 20200402204138eucas1p106e0c8eb8b7aa4c3ce78a7c457b10881~CG1uNuaUm0558105581eucas1p1W; Thu, 2 Apr 2020 20:41:38 +0000 (GMT) Received: from eusmgms2.samsung.com (unknown [182.198.249.180]) by eusmtrp2.samsung.com (KnoxPortal) with ESMTP id 20200402204138eusmtrp2d76c46a424beab04ff38b3d06836cd86~CG1uNAJ5i0564505645eusmtrp22; Thu, 2 Apr 2020 20:41:38 +0000 (GMT) X-AuditID: cbfec7f2-ef1ff7000001ef66-b7-5e864e036031 Received: from eusmtip2.samsung.com ( [203.254.199.222]) by eusmgms2.samsung.com (EUCPMTA) with SMTP id E5.9F.07950.20E468E5; Thu, 2 Apr 2020 21:41:38 +0100 (BST) Received: from [106.109.129.29] (unknown [106.109.129.29]) by eusmtip2.samsung.com (KnoxPortal) with ESMTPA id 20200402204138eusmtip2a2b7ccf0df8b224d5e9693cd22d59f2b~CG1tfYWkE2900529005eusmtip25; Thu, 2 Apr 2020 20:41:37 +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, 'Vladimir Kuramshin' , amorenoz@redhat.com, zhihong.wang@intel.com, xiaolong.ye@intel.com From: Ivan Dyukov Message-ID: Date: Thu, 2 Apr 2020 23:41:37 +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: <98CBD80474FA8B44BF855DF32C47DC35C60F3A@smartserver.smartshare.dk> Content-Transfer-Encoding: 8bit Content-Language: ru-RU X-Brightmail-Tracker: H4sIAAAAAAAAA01SfSxVcRjud8659x7m2nFp3tFW7vpDtcjUdlamTGtHpY+tttSii+MjXHYP Sv5RYTeV2U3oSpRVplbi+siufJWPbjJiZaFb3RHiSphvufew/Pe8z/O8v+d9th+JS3oEDmS4 PJZVyGWRUqElUdE0274TP5bqv0tTjdMpVXqC1mf2CemZn+lCemyiEqN7a3Qi+kleHk433dAS dPpcN6In9C0ErespE9ELv/fQZR0q7IAVkzn/SsDMFTwWMIXaIYwZyG7EmKaeLBFjfNMtZNI1 xYh5/+MmzjwzzAhPWJy19AhmI8PjWYWr5wXLMEPLHxST43T5ebeBSEJtjmnIggRqN3xrv4On IUtSQhUh6K/VifhhEkFtwwjGD38RaI1taG3FUJ5E8MJTBHc7+hE/GBEMX1WaXbbUaeh7e01o EuyoGgQFumVzCm56uPj7pMDkElLOoFM+wExYTHlCbu8MbsIEtRV+9U6b8UbqDGRVLiHeYwOt 9wyECVtQx6G0+7aZx6nNcL08F+exPYxX1puTgZoVwYuFOoI//CAoPytXsS0MN2tEPN4Ey6/z MR4ngjZtVMQvKxFMJZWvtt4PmpGPKwK5krANXla78rQXVJSVCEw0UNbwZdSGv8EaVBXZOE+L QZkq4d1SqGvtXKUBFuetMpBUva6Yel0Z9boy6v+xBYgoRvZsHBcVynJucvaSCyeL4uLkoS5B 0VGlaOXD6ZaaJ6rQVGdgA6JIJLUSb6hP8ZcIZPFcQlQDAhKX2om9clYocbAs4QqriA5QxEWy XANyJAmpvdj90dB5CRUqi2UjWDaGVaypGGnhkITuFyUaE+qn4/SHtEvVIyr/kOih+EH9rCYx WL4vRBj2qfqURDXwIW1xRqsqqQ9Pdd/ysLwrMvNoznzQoDGn7UjguLdfYkRAYeo5Y3+Gb8LS wuzhjEafiwYqQm0XtPdWfqfjV2cnb6d3Mo9pZ863ayzMZ4dfSfLJ4cG+ISw/WWtbKiW4MJnb dlzByf4BL0wU92wDAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsVy+t/xe7pMfm1xBs++6Fq07njAYvFgyl02 ix+P+9gs3n3azmRxZ+9pdotlc+cyWxzr3MNi0ffrKqPFpwcnWCxO39zMbvHnjanF5ouTmBx4 PKb83sjq8WvBUlaPxXteMnk8m36YyePYzWnsHu/3XWXz6NuyitHj1KNuZo/VT36wBXBG6dkU 5ZeWpCpk5BeX2CpFG1oY6RlaWugZmVjqGRqbx1oZmSrp29mkpOZklqUW6dsl6GU8OfGRsWCG YsWaq09YGhjPSncxcnJICJhIPNnawNLFyMUhJLCUUeLYmh/MXYwcQAkJiddPmCFqhCX+XOti g6h5yyhx//gTdpCEsECoxN0jTWAJEYG9jBLLGnYxgjjMAl8YJRY83coI0fKHSeLdhf2sIC1s AhoSpzvmMYHYvAJ2ErPv/ADbwSKgIvHizjcwW1QgQuLxxHZGiBpBiZMzn7CA2JwC/hKbrvaC xZkFzCTmbX7IDGHLSzRvnQ1li0t82H6QbQKj0Cwk7bOQtMxC0jILScsCRpZVjCKppcW56bnF RnrFibnFpXnpesn5uZsYgTG97djPLTsYu94FH2IU4GBU4uFlONgaJ8SaWFZcmXuIUYKDWUmE 13EGUIg3JbGyKrUoP76oNCe1+BCjKdBzE5mlRJPzgekmryTe0NTQ3MLS0NzY3NjMQkmct0Pg YIyQQHpiSWp2ampBahFMHxMHp1QDI6/461tfgvw33e55dvaW4S6WRdqCwfs/WTv+t6nLUj5p yGAZukjwfJrQHFtjiZClXyqD3BS8f9tzBCRlKlbxvnjc7vqsvNlw7ry73WdsJQMTbgV6sn2W 3yE5++E9zjRXjTNZXJf4zs6Vzyp092l7Me2NXLMH7+opjDM0VJlVf+VXCPIuLZqrxFKckWio xVxUnAgAHw3f+/8CAAA= X-CMS-MailID: 20200402204138eucas1p106e0c8eb8b7aa4c3ce78a7c457b10881 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> <98CBD80474FA8B44BF855DF32C47DC35C60F3A@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" 02.04.2020 16:50, Morten Brørup пишет: >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ivan Dyukov >> Sent: Thursday, April 2, 2020 2:54 PM >> >> 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=https://protect2.fireeye.com/url?k=b77dd9ba-ea1a9d9c-b77c52f5-0cc47a31384a-83e04670981c13ea&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://protect2.fireeye.com/url?k=1e499600-432ed226-1e481d4f-0cc47a31384a-5c4e61a49cf9986a&u=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. > Very interesting link, indeed! > > 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 ports. > > It also provides a special value for unknown speed. > >>>>> 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=https://protect2.fireeye.com/url?k=13709c46-4e17d860-13711709-0cc47a31384a-b18536864970b070&u=http://inbox.dpdk.org/dev/AM0PR0502MB401907ADE7CEA27 >> DC642DF35D2CB0@AM0P >>>> R0502MB4019.eurprd05.prod.outlook.com/T/#t >>>> >>>> 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. >>> 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? > Your link to the Kernel/QEMU patch answers this question: Yes, because we assume it reflects the underlying speed. > >