[{"id":1775189,"web_url":"http://patchwork.ozlabs.org/comment/1775189/","msgid":"","list_archive_url":null,"date":"2017-09-26T06:43:41","subject":"RE: [PATCH v2 net-next 10/10] net: hns3: Add mqprio support when\n\tinteracting with network stack","submitter":{"id":72439,"url":"http://patchwork.ozlabs.org/api/people/72439/","name":"Yuval Mintz","email":"yuvalm@mellanox.com"},"content":"> When using tc qdisc to configure DCB parameter, dcb_ops->setup_tc\n> is used to tell hclge_dcb module to do the setup.\n\nWhile this might be a step in the right direction, this causes an inconsistency\nin user experience - Some [well, most] vendors didn't allow the mqprio\npriority mapping to affect DCB, instead relying on the dcbnl functionality\nto control that configuration.\n\nA couple of options to consider:\n - Perhaps said logic shouldn't be contained inside the driver but rather\n in mqprio logic itself. I.e., rely on DCBNL functionality [if available] from\n within mqprio and try changing the configuration. \n - Add a new TC_MQPRIO_HW_OFFLOAD_ value to explicitly reflect user\n request to allow this configuration to affect DCB.\n\n> When using lldptool to configure DCB parameter, hclge_dcb module\n> call the client_ops->setup_tc to tell network stack which queue\n> and priority is using for specific tc.\n\nYou're basically bypassing the mqprio logic.\nSince you're configuring the prio->queue mapping from DCB flow,\nyou'll get an mqprio-like behavior [meaning a transmitted packet\nwould reach a transmission queue associated with its priority] even\nif device wasn't grated with an mqprio qdisc.\nWhy should your user even use mqprio? What benefit does he get from it?\n\n...\n\n> +static int hns3_nic_set_real_num_queue(struct net_device *netdev)\n> +{\n> +\tstruct hns3_nic_priv *priv = netdev_priv(netdev);\n> +\tstruct hnae3_handle *h = priv->ae_handle;\n> +\tstruct hnae3_knic_private_info *kinfo = &h->kinfo;\n> +\tunsigned int queue_size = kinfo->rss_size * kinfo->num_tc;\n> +\tint ret;\n> +\n> +\tret = netif_set_real_num_tx_queues(netdev, queue_size);\n> +\tif (ret) {\n> +\t\tnetdev_err(netdev,\n> +\t\t\t \"netif_set_real_num_tx_queues fail, ret=%d!\\n\",\n> +\t\t\t ret);\n> +\t\treturn ret;\n> +\t}\n> +\n> +\tret = netif_set_real_num_rx_queues(netdev, queue_size);\n\nI don't think you're changing the driver behavior, but why are you setting\nthe real number of rx queues based on the number of TCs?\nDo you actually open (TC x RSS) Rx queues?","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=Mellanox.com header.i=@Mellanox.com\n\theader.b=\"LeKQrjyT\"; dkim-atps=neutral","spf=none (sender IP is )\n\tsmtp.mailfrom=yuvalm@mellanox.com; "],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y1Wd96z9pz9tX4\n\tfor ;\n\tTue, 26 Sep 2017 16:43:57 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S936037AbdIZGnr (ORCPT );\n\tTue, 26 Sep 2017 02:43:47 -0400","from mail-eopbgr40079.outbound.protection.outlook.com\n\t([40.107.4.79]:32717\n\t\"EHLO EUR03-DB5-obe.outbound.protection.outlook.com\"\n\trhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP\n\tid S935399AbdIZGnn (ORCPT );\n\tTue, 26 Sep 2017 02:43:43 -0400","from AM0PR0502MB3683.eurprd05.prod.outlook.com (52.133.46.152) by\n\tAM0PR0502MB3684.eurprd05.prod.outlook.com (52.133.46.153) with\n\tMicrosoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id\n\t15.20.77.7; Tue, 26 Sep 2017 06:43:41 +0000","from AM0PR0502MB3683.eurprd05.prod.outlook.com\n\t([fe80::5cbd:456e:e0ba:bbde]) by\n\tAM0PR0502MB3683.eurprd05.prod.outlook.com\n\t([fe80::5cbd:456e:e0ba:bbde%13]) with mapi id 15.20.0077.011;\n\tTue, 26 Sep 2017 06:43:41 +0000"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com;\n\ts=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;\n\tbh=3GCe7rAVLLmLnt9leIIJQuwnoEl9nFDB7ElfZJX8N9M=;\n\tb=LeKQrjyTwFPeMcuWdRYyg9jb5eySH0w41WenxOPDrc4G4VSGrYCJ/BCwlV0AoveC2us38can793lTTcQXc+q1qKEFmQ0cXIbW06cZk4x+lirW2C32No4Nyh2w0wPv8Y94EkT7ec4dsUSPs05I8+naEye5JqwiE34990leHMEDfA=","From":"Yuval Mintz ","To":"Yunsheng Lin ","CC":"\"huangdaode@hisilicon.com\" ,\n\t\"xuwei5@hisilicon.com\" ,\n\t\"liguozhu@hisilicon.com\" ,\n\t\"Yisen.Zhuang@huawei.com\" ,\n\t\"gabriele.paoloni@huawei.com\" ,\n\t\"john.garry@huawei.com\" ,\n\t\"linuxarm@huawei.com\" ,\n\t\"yisen.zhuang@huawei.com\" ,\n\t\"salil.mehta@huawei.com\" ,\n\t\"lipeng321@huawei.com\" ,\n\t\"netdev@vger.kernel.org\" ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\t\"davem@davemloft.net\" ","Subject":"RE: [PATCH v2 net-next 10/10] net: hns3: Add mqprio support when\n\tinteracting with network stack","Thread-Topic":"[PATCH v2 net-next 10/10] net: hns3: Add mqprio support when\n\tinteracting with network stack","Thread-Index":"AQHTNm760RsBmPn/P0qzMTftPnVtNaLGs2sg","Date":"Tue, 26 Sep 2017 06:43:41 +0000","Message-ID":"","References":"<1506392718-50463-1-git-send-email-linyunsheng@huawei.com>\n\t<1506392718-50463-11-git-send-email-linyunsheng@huawei.com>","In-Reply-To":"<1506392718-50463-11-git-send-email-linyunsheng@huawei.com>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","authentication-results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=Mellanox.com header.i=@Mellanox.com\n\theader.b=\"LeKQrjyT\"; dkim-atps=neutral","spf=none (sender IP is )\n\tsmtp.mailfrom=yuvalm@mellanox.com; "],"x-originating-ip":"[193.47.165.251]","x-ms-publictraffictype":"Email","x-microsoft-exchange-diagnostics":"1; AM0PR0502MB3684;\n\t6:AtQGPvDoIgngyE5ZTyuGffvjuWsWwn4Yslxr28VNPKqqi/YdKSJxytQQB6Xu2SM3gp3mhyH5q7vC8T0zvBW1t2bT6tmHBy+ZKvRx7eH4i/3OUgRiOedWbsyVQvLE7/o6sjfbsWcidivEJJWNYSS61NPKuK5pbO+v/swm/jX3O/N8xME2Tz1uRDaMUcj/kfPGbDjxdg0wZMmvXxUO+pVQcY7aOhV+P9aA1ROCJFnF0ieZ0ZinvZ8GuXsnv3/WVU0cPshAiQsz6359Bls/gy1ukOsOkTgrMk4pgBsC+ZWjbzXnAcciDAFIe0CtpHOXtqnBA/HWxuxzik0mO8scmJG4Ow==;\n\t5:UKxSu5UGrQSwXz1d0t7lrMo95N+TF7U4v29LZq6PxXTnn3ICaW66t0/eh9h7y381s+GJIWBe8fCUjQPxLUbOt2IZipQHkkK3w+CzyXbMERU3v3dKyKtTCwDyIxUyqvpiUD+ApF9fJk7fSB0y2tJtmA==;\n\t24:BEpQyVZ3lV0g7PlC4ZboJT+sgz98GzYMBctkDM/UqELMqslupQkwcshC9T0GEJzyjn8w0QGL9yiXpmuss8DXjxeCQAVBFTvRiF2tb2oz0bQ=;\n\t7:JzberSfIYEexyPnLK7Z9hsrkSSRB8POpxh3bZ56N/TYT66/I8q2V8boM31v+eA2+AcqUkp4k8yHzLIvYS9rt/OM5h3W0A1u9PLGF5ylWSHirk0N1akLJ/oi33QN7hOUIwgAnaYVgMlwzJIkFookOm7+E3ffyDCOS/RCq6pirXuGnugq4jQTC+eFC7eZwk5bZzO9A8OUbRJWFsArJCuQtpdZMoHd+V2yXKDQYL06Vxh8=","x-ms-exchange-antispam-srfa-diagnostics":"SSOS;","x-ms-office365-filtering-correlation-id":"a0f85efd-2042-4ed2-9953-08d504a9ecdf","x-ms-office365-filtering-ht":"Tenant","x-microsoft-antispam":"UriScan:; BCL:0; PCL:0;\n\tRULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075);\n\tSRVR:AM0PR0502MB3684; ","x-ms-traffictypediagnostic":"AM0PR0502MB3684:","x-exchange-antispam-report-test":"UriScan:(17755550239193);","x-microsoft-antispam-prvs":"","x-exchange-antispam-report-cfa-test":"BCL:0; PCL:0;\n\tRULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);\n\tSRVR:AM0PR0502MB3684; BCL:0; PCL:0;\n\tRULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);\n\tSRVR:AM0PR0502MB3684; ","x-forefront-prvs":"0442E569BC","x-forefront-antispam-report":"SFV:NSPM;\n\tSFS:(10009020)(6009001)(346002)(39860400002)(376002)(189002)(199003)(9686003)(14454004)(5660300001)(2906002)(3660700001)(3280700002)(68736007)(7736002)(7416002)(86362001)(8936002)(53936002)(54356999)(81166006)(305945005)(6916009)(7696004)(81156014)(55016002)(2950100002)(76176999)(50986999)(99286003)(8676002)(5250100002)(478600001)(101416001)(229853002)(6116002)(3846002)(102836003)(66066001)(74316002)(2900100001)(189998001)(97736004)(105586002)(33656002)(316002)(6506006)(4326008)(106356001)(25786009)(6246003)(6436002)(54906003);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR0502MB3684;\n\tH:AM0PR0502MB3683.eurprd05.prod.outlook.com; FPR:; SPF:None;\n\tPTR:InfoNoRecords; MX:1; A:1; LANG:en; ","received-spf":"None (protection.outlook.com: mellanox.com does not designate\n\tpermitted sender hosts)","spamdiagnosticoutput":"1:99","spamdiagnosticmetadata":"NSPM","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"quoted-printable","MIME-Version":"1.0","X-OriginatorOrg":"Mellanox.com","X-MS-Exchange-CrossTenant-originalarrivaltime":"26 Sep 2017 06:43:41.2072\n\t(UTC)","X-MS-Exchange-CrossTenant-fromentityheader":"Hosted","X-MS-Exchange-CrossTenant-id":"a652971c-7d2e-4d9b-a6a4-d149256f461b","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"AM0PR0502MB3684","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1775209,"web_url":"http://patchwork.ozlabs.org/comment/1775209/","msgid":"","list_archive_url":null,"date":"2017-09-26T07:29:03","subject":"Re: [PATCH v2 net-next 10/10] net: hns3: Add mqprio support when\n\tinteracting with network stack","submitter":{"id":71804,"url":"http://patchwork.ozlabs.org/api/people/71804/","name":"Yunsheng Lin","email":"linyunsheng@huawei.com"},"content":"Hi, Yuval\n\nOn 2017/9/26 14:43, Yuval Mintz wrote:\n>> When using tc qdisc to configure DCB parameter, dcb_ops->setup_tc\n>> is used to tell hclge_dcb module to do the setup.\n> \n> While this might be a step in the right direction, this causes an inconsistency\n> in user experience - Some [well, most] vendors didn't allow the mqprio\n> priority mapping to affect DCB, instead relying on the dcbnl functionality\n> to control that configuration.\n> \n> A couple of options to consider:\n> - Perhaps said logic shouldn't be contained inside the driver but rather\n> in mqprio logic itself. I.e., rely on DCBNL functionality [if available] from\n> within mqprio and try changing the configuration. \n> - Add a new TC_MQPRIO_HW_OFFLOAD_ value to explicitly reflect user\n> request to allow this configuration to affect DCB.\n> \n>> When using lldptool to configure DCB parameter, hclge_dcb module\n>> call the client_ops->setup_tc to tell network stack which queue\n>> and priority is using for specific tc.\n> \n> You're basically bypassing the mqprio logic.\n> Since you're configuring the prio->queue mapping from DCB flow,\n> you'll get an mqprio-like behavior [meaning a transmitted packet\n> would reach a transmission queue associated with its priority] even\n> if device wasn't grated with an mqprio qdisc.\n> Why should your user even use mqprio? What benefit does he get from it?\n\n\nWhen adding mqprio and lldptool support, I was thinking user can use\ntc qdisc or lldptool to do the configuration, giving user two option to\nsetup the DCB.\n\nIf user is only tc qdisc or lldptool, I think there is no problem here.\n\nwhen user is using tc qdisc and lldptool, As you explained above, When\ntc qdisc changes the configuration, there should be a way to notify dcbnl,\nso that the dcbnl can response correctly(like tell the peer it's configuration\nhas changed).\n\nI will try to find if there is a way to do notify the dcbnl when using tc qdisc\nto setup the configuration.\nIf there is not a way to do it now, then I will drop the mqprio in this patch, and\nwill address this problem if there is need for the tc qdisc.\n\nPlease let me know if I was misunderstood.\nAnd thanks for your time reviewing.\n\n> \n> ...\n> \n>> +static int hns3_nic_set_real_num_queue(struct net_device *netdev)\n>> +{\n>> +\tstruct hns3_nic_priv *priv = netdev_priv(netdev);\n>> +\tstruct hnae3_handle *h = priv->ae_handle;\n>> +\tstruct hnae3_knic_private_info *kinfo = &h->kinfo;\n>> +\tunsigned int queue_size = kinfo->rss_size * kinfo->num_tc;\n>> +\tint ret;\n>> +\n>> +\tret = netif_set_real_num_tx_queues(netdev, queue_size);\n>> +\tif (ret) {\n>> +\t\tnetdev_err(netdev,\n>> +\t\t\t \"netif_set_real_num_tx_queues fail, ret=%d!\\n\",\n>> +\t\t\t ret);\n>> +\t\treturn ret;\n>> +\t}\n>> +\n>> +\tret = netif_set_real_num_rx_queues(netdev, queue_size);\n> \n> I don't think you're changing the driver behavior, but why are you setting\n> the real number of rx queues based on the number of TCs?\n> Do you actually open (TC x RSS) Rx queues?\n> \n> .\n>","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y1Xdz6kXwz9t3h\n\tfor ;\n\tTue, 26 Sep 2017 17:29:43 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S967386AbdIZH3Y (ORCPT );\n\tTue, 26 Sep 2017 03:29:24 -0400","from szxga05-in.huawei.com ([45.249.212.191]:7019 \"EHLO\n\tszxga05-in.huawei.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S936387AbdIZH3V (ORCPT\n\t); Tue, 26 Sep 2017 03:29:21 -0400","from 172.30.72.58 (EHLO DGGEMS411-HUB.china.huawei.com)\n\t([172.30.72.58])\n\tby dggrg05-dlp.huawei.com (MOS 4.4.6-GA FastPath queued)\n\twith ESMTP id DIA98163; Tue, 26 Sep 2017 15:29:14 +0800 (CST)","from [127.0.0.1] (10.74.191.121) by DGGEMS411-HUB.china.huawei.com\n\t(10.3.19.211) with Microsoft SMTP Server id 14.3.301.0;\n\tTue, 26 Sep 2017 15:29:04 +0800"],"Subject":"Re: [PATCH v2 net-next 10/10] net: hns3: Add mqprio support when\n\tinteracting with network stack","To":"Yuval Mintz ","CC":"\"huangdaode@hisilicon.com\" ,\n\t\"xuwei5@hisilicon.com\" ,\n\t\"liguozhu@hisilicon.com\" ,\n\t\"Yisen.Zhuang@huawei.com\" ,\n\t\"gabriele.paoloni@huawei.com\" ,\n\t\"john.garry@huawei.com\" ,\n\t\"linuxarm@huawei.com\" ,\n\t\"salil.mehta@huawei.com\" ,\n\t\"lipeng321@huawei.com\" ,\n\t\"netdev@vger.kernel.org\" ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\t\"davem@davemloft.net\" ","References":"<1506392718-50463-1-git-send-email-linyunsheng@huawei.com>\n\t<1506392718-50463-11-git-send-email-linyunsheng@huawei.com>\n\t","From":"Yunsheng Lin ","Message-ID":"","Date":"Tue, 26 Sep 2017 15:29:03 +0800","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=\"utf-8\"","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-Originating-IP":"[10.74.191.121]","X-CFilter-Loop":"Reflected","X-Mirapoint-Virus-RAPID-Raw":"score=unknown(0),\n\trefid=str=0001.0A090203.59CA01CA.0056, ss=1, re=0.000, recu=0.000,\n\treip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,\n\tso=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32","X-Mirapoint-Loop-Id":"c76adcc21de481378508f32c3decbe87","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1775211,"web_url":"http://patchwork.ozlabs.org/comment/1775211/","msgid":"<7716ff26-92fe-165e-8b5e-147914608032@huawei.com>","list_archive_url":null,"date":"2017-09-26T07:33:27","subject":"Re: [PATCH v2 net-next 10/10] net: hns3: Add mqprio support when\n\tinteracting with network stack","submitter":{"id":71804,"url":"http://patchwork.ozlabs.org/api/people/71804/","name":"Yunsheng Lin","email":"linyunsheng@huawei.com"},"content":"Hi, Yuval\n\nOn 2017/9/26 14:43, Yuval Mintz wrote:\n>> When using tc qdisc to configure DCB parameter, dcb_ops->setup_tc\n>> is used to tell hclge_dcb module to do the setup.\n> \n> While this might be a step in the right direction, this causes an inconsistency\n> in user experience - Some [well, most] vendors didn't allow the mqprio\n> priority mapping to affect DCB, instead relying on the dcbnl functionality\n> to control that configuration.\n> \n> A couple of options to consider:\n> - Perhaps said logic shouldn't be contained inside the driver but rather\n> in mqprio logic itself. I.e., rely on DCBNL functionality [if available] from\n> within mqprio and try changing the configuration. \n> - Add a new TC_MQPRIO_HW_OFFLOAD_ value to explicitly reflect user\n> request to allow this configuration to affect DCB.\n> \n>> When using lldptool to configure DCB parameter, hclge_dcb module\n>> call the client_ops->setup_tc to tell network stack which queue\n>> and priority is using for specific tc.\n> \n> You're basically bypassing the mqprio logic.\n> Since you're configuring the prio->queue mapping from DCB flow,\n> you'll get an mqprio-like behavior [meaning a transmitted packet\n> would reach a transmission queue associated with its priority] even\n> if device wasn't grated with an mqprio qdisc.\n> Why should your user even use mqprio? What benefit does he get from it?\n> \n> ...\n> \n>> +static int hns3_nic_set_real_num_queue(struct net_device *netdev)\n>> +{\n>> +\tstruct hns3_nic_priv *priv = netdev_priv(netdev);\n>> +\tstruct hnae3_handle *h = priv->ae_handle;\n>> +\tstruct hnae3_knic_private_info *kinfo = &h->kinfo;\n>> +\tunsigned int queue_size = kinfo->rss_size * kinfo->num_tc;\n>> +\tint ret;\n>> +\n>> +\tret = netif_set_real_num_tx_queues(netdev, queue_size);\n>> +\tif (ret) {\n>> +\t\tnetdev_err(netdev,\n>> +\t\t\t \"netif_set_real_num_tx_queues fail, ret=%d!\\n\",\n>> +\t\t\t ret);\n>> +\t\treturn ret;\n>> +\t}\n>> +\n>> +\tret = netif_set_real_num_rx_queues(netdev, queue_size);\n> \n> I don't think you're changing the driver behavior, but why are you setting\n> the real number of rx queues based on the number of TCs?\n> Do you actually open (TC x RSS) Rx queues?\n\nYes, our hardware can do the rss based on TC.\n\nSorry for almost forget to answer this question.\nThanks for your time reviewing again.\n\n> \n> .\n>","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y1Xkt3f69z9tXb\n\tfor ;\n\tTue, 26 Sep 2017 17:33:58 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S966493AbdIZHds (ORCPT );\n\tTue, 26 Sep 2017 03:33:48 -0400","from szxga05-in.huawei.com ([45.249.212.191]:7020 \"EHLO\n\tszxga05-in.huawei.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S935108AbdIZHdq (ORCPT\n\t); Tue, 26 Sep 2017 03:33:46 -0400","from 172.30.72.59 (EHLO DGGEMS412-HUB.china.huawei.com)\n\t([172.30.72.59])\n\tby dggrg05-dlp.huawei.com (MOS 4.4.6-GA FastPath queued)\n\twith ESMTP id DIA98849; Tue, 26 Sep 2017 15:33:36 +0800 (CST)","from [127.0.0.1] (10.74.191.121) by DGGEMS412-HUB.china.huawei.com\n\t(10.3.19.212) with Microsoft SMTP Server id 14.3.301.0;\n\tTue, 26 Sep 2017 15:33:28 +0800"],"Subject":"Re: [PATCH v2 net-next 10/10] net: hns3: Add mqprio support when\n\tinteracting with network stack","To":"Yuval Mintz ","CC":"\"huangdaode@hisilicon.com\" ,\n\t\"xuwei5@hisilicon.com\" ,\n\t\"liguozhu@hisilicon.com\" ,\n\t\"Yisen.Zhuang@huawei.com\" ,\n\t\"gabriele.paoloni@huawei.com\" ,\n\t\"john.garry@huawei.com\" ,\n\t\"linuxarm@huawei.com\" ,\n\t\"salil.mehta@huawei.com\" ,\n\t\"lipeng321@huawei.com\" ,\n\t\"netdev@vger.kernel.org\" ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\t\"davem@davemloft.net\" ","References":"<1506392718-50463-1-git-send-email-linyunsheng@huawei.com>\n\t<1506392718-50463-11-git-send-email-linyunsheng@huawei.com>\n\t","From":"Yunsheng Lin ","Message-ID":"<7716ff26-92fe-165e-8b5e-147914608032@huawei.com>","Date":"Tue, 26 Sep 2017 15:33:27 +0800","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=\"utf-8\"","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-Originating-IP":"[10.74.191.121]","X-CFilter-Loop":"Reflected","X-Mirapoint-Virus-RAPID-Raw":"score=unknown(0),\n\trefid=str=0001.0A090204.59CA02D0.0062, ss=1, re=0.000, recu=0.000,\n\treip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,\n\tso=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32","X-Mirapoint-Loop-Id":"c76adcc21de481378508f32c3decbe87","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1775358,"web_url":"http://patchwork.ozlabs.org/comment/1775358/","msgid":"<3fe662df-a216-4966-863c-d98555ef3ed2@huawei.com>","list_archive_url":null,"date":"2017-09-26T10:49:14","subject":"Re: [PATCH v2 net-next 10/10] net: hns3: Add mqprio support when\n\tinteracting with network stack","submitter":{"id":71804,"url":"http://patchwork.ozlabs.org/api/people/71804/","name":"Yunsheng Lin","email":"linyunsheng@huawei.com"},"content":"Hi, Yuval\n\nOn 2017/9/26 14:43, Yuval Mintz wrote:\n>> When using tc qdisc to configure DCB parameter, dcb_ops->setup_tc\n>> is used to tell hclge_dcb module to do the setup.\n> \n> While this might be a step in the right direction, this causes an inconsistency\n> in user experience - Some [well, most] vendors didn't allow the mqprio\n> priority mapping to affect DCB, instead relying on the dcbnl functionality\n> to control that configuration.\n> \n> A couple of options to consider:\n> - Perhaps said logic shouldn't be contained inside the driver but rather\n> in mqprio logic itself. I.e., rely on DCBNL functionality [if available] from\n> within mqprio and try changing the configuration. \n\nIn net/dcb/dcbnl.c\ndcbnl_ieee_set already call dcbnl_ieee_notify to notify the user space\nconfiguration has changed, does this dcbnl_ieee_notify function do the\njob for us? I am not sure if lldpad has registered for this notifition.\n\nAs you suggested below, can we add a new TC_MQPRIO_HW_OFFLOAD_ value to\nreflect that the configuration is needed to be changed by dcbnl_ieee_set\n(perhaps some other function) in dcbnl?\nDo you think it is feasible?\n\n\n> - Add a new TC_MQPRIO_HW_OFFLOAD_ value to explicitly reflect user\n> request to allow this configuration to affect DCB.\n> \n>> When using lldptool to configure DCB parameter, hclge_dcb module\n>> call the client_ops->setup_tc to tell network stack which queue\n>> and priority is using for specific tc.\n> \n> You're basically bypassing the mqprio logic.\n> Since you're configuring the prio->queue mapping from DCB flow,\n> you'll get an mqprio-like behavior [meaning a transmitted packet\n> would reach a transmission queue associated with its priority] even\n> if device wasn't grated with an mqprio qdisc.\n> Why should your user even use mqprio? What benefit does he get from it?\n> \n> ...\n> \n>> +static int hns3_nic_set_real_num_queue(struct net_device *netdev)\n>> +{\n>> +\tstruct hns3_nic_priv *priv = netdev_priv(netdev);\n>> +\tstruct hnae3_handle *h = priv->ae_handle;\n>> +\tstruct hnae3_knic_private_info *kinfo = &h->kinfo;\n>> +\tunsigned int queue_size = kinfo->rss_size * kinfo->num_tc;\n>> +\tint ret;\n>> +\n>> +\tret = netif_set_real_num_tx_queues(netdev, queue_size);\n>> +\tif (ret) {\n>> +\t\tnetdev_err(netdev,\n>> +\t\t\t \"netif_set_real_num_tx_queues fail, ret=%d!\\n\",\n>> +\t\t\t ret);\n>> +\t\treturn ret;\n>> +\t}\n>> +\n>> +\tret = netif_set_real_num_rx_queues(netdev, queue_size);\n> \n> I don't think you're changing the driver behavior, but why are you setting\n> the real number of rx queues based on the number of TCs?\n> Do you actually open (TC x RSS) Rx queues?\n> \n> .\n>","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y1d4h5WGZz9t3x\n\tfor ;\n\tTue, 26 Sep 2017 20:49:40 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S967911AbdIZKta (ORCPT );\n\tTue, 26 Sep 2017 06:49:30 -0400","from szxga05-in.huawei.com ([45.249.212.191]:7024 \"EHLO\n\tszxga05-in.huawei.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S967851AbdIZKt3 (ORCPT\n\t); Tue, 26 Sep 2017 06:49:29 -0400","from 172.30.72.59 (EHLO DGGEMS409-HUB.china.huawei.com)\n\t([172.30.72.59])\n\tby dggrg05-dlp.huawei.com (MOS 4.4.6-GA FastPath queued)\n\twith ESMTP id DIB28262; Tue, 26 Sep 2017 18:49:20 +0800 (CST)","from [127.0.0.1] (10.74.191.121) by DGGEMS409-HUB.china.huawei.com\n\t(10.3.19.209) with Microsoft SMTP Server id 14.3.301.0;\n\tTue, 26 Sep 2017 18:49:13 +0800"],"Subject":"Re: [PATCH v2 net-next 10/10] net: hns3: Add mqprio support when\n\tinteracting with network stack","To":"Yuval Mintz ","CC":"\"huangdaode@hisilicon.com\" ,\n\t\"xuwei5@hisilicon.com\" ,\n\t\"liguozhu@hisilicon.com\" ,\n\t\"Yisen.Zhuang@huawei.com\" ,\n\t\"gabriele.paoloni@huawei.com\" ,\n\t\"john.garry@huawei.com\" ,\n\t\"linuxarm@huawei.com\" ,\n\t\"salil.mehta@huawei.com\" ,\n\t\"lipeng321@huawei.com\" ,\n\t\"netdev@vger.kernel.org\" ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\t\"davem@davemloft.net\" ","References":"<1506392718-50463-1-git-send-email-linyunsheng@huawei.com>\n\t<1506392718-50463-11-git-send-email-linyunsheng@huawei.com>\n\t","From":"Yunsheng Lin ","Message-ID":"<3fe662df-a216-4966-863c-d98555ef3ed2@huawei.com>","Date":"Tue, 26 Sep 2017 18:49:14 +0800","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=\"utf-8\"","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-Originating-IP":"[10.74.191.121]","X-CFilter-Loop":"Reflected","X-Mirapoint-Virus-RAPID-Raw":"score=unknown(0),\n\trefid=str=0001.0A090201.59CA30B1.01BE, ss=1, re=0.000, recu=0.000,\n\treip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,\n\tso=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32","X-Mirapoint-Loop-Id":"c76adcc21de481378508f32c3decbe87","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1775427,"web_url":"http://patchwork.ozlabs.org/comment/1775427/","msgid":"","list_archive_url":null,"date":"2017-09-26T12:29:02","subject":"RE: [PATCH v2 net-next 10/10] net: hns3: Add mqprio support when\n\tinteracting with network stack","submitter":{"id":72439,"url":"http://patchwork.ozlabs.org/api/people/72439/","name":"Yuval Mintz","email":"yuvalm@mellanox.com"},"content":"> Hi, Yuval\r\n> \r\n> On 2017/9/26 14:43, Yuval Mintz wrote:\r\n> >> When using tc qdisc to configure DCB parameter, dcb_ops->setup_tc\r\n> >> is used to tell hclge_dcb module to do the setup.\r\n> >\r\n> > While this might be a step in the right direction, this causes an inconsistency\r\n> > in user experience - Some [well, most] vendors didn't allow the mqprio\r\n> > priority mapping to affect DCB, instead relying on the dcbnl functionality\r\n> > to control that configuration.\r\n> >\r\n> > A couple of options to consider:\r\n> > - Perhaps said logic shouldn't be contained inside the driver but rather\r\n> > in mqprio logic itself. I.e., rely on DCBNL functionality [if available] from\r\n> > within mqprio and try changing the configuration.\r\n> \r\n> In net/dcb/dcbnl.c\r\n> dcbnl_ieee_set already call dcbnl_ieee_notify to notify the user space\r\n> configuration has changed, does this dcbnl_ieee_notify function do the\r\n> job for us? I am not sure if lldpad has registered for this notifition.\r\n\r\nNot that familiar with the dcbnl calls; Shouldn't dcbnl_setall be called to\r\nmake the configuration apply [or is that only for ieee]?\r\nRegardless, don't know if it makes sense to assume user-application would\r\nfix the qdisc configuration by notification while dcbnl logic in kernel could have\r\ndone that instead.\r\n\r\n> As you suggested below, can we add a new TC_MQPRIO_HW_OFFLOAD_\r\n> value to\r\n> reflect that the configuration is needed to be changed by dcbnl_ieee_set\r\n> (perhaps some other function) in dcbnl?\r\n> Do you think it is feasible?\r\n\r\nEither I'm miseading your answer or we think of it from 2 opposite end.\r\nI was thinking that the new offloaded flag would indicate to the underlying\r\ndriver that it's expected to offload the prio mapping [as part of DCB].\r\nIf the driver would be incapable of that it would refuse the offload.\r\nUser would then have to explicitly request that the qdisc offload.\r\n\r\n> \r\n> \r\n> > - Add a new TC_MQPRIO_HW_OFFLOAD_ value to explicitly reflect user\r\n> > request to allow this configuration to affect DCB.\r\n> >\r\n> >> When using lldptool to configure DCB parameter, hclge_dcb module\r\n> >> call the client_ops->setup_tc to tell network stack which queue\r\n> >> and priority is using for specific tc.\r\n> >\r\n> > You're basically bypassing the mqprio logic.\r\n> > Since you're configuring the prio->queue mapping from DCB flow,\r\n> > you'll get an mqprio-like behavior [meaning a transmitted packet\r\n> > would reach a transmission queue associated with its priority] even\r\n> > if device wasn't grated with an mqprio qdisc.\r\n> > Why should your user even use mqprio? What benefit does he get from it?\r\n> >\r\n> > ...\r\n> >\r\n> >> +static int hns3_nic_set_real_num_queue(struct net_device *netdev)\r\n> >> +{\r\n> >> +\tstruct hns3_nic_priv *priv = netdev_priv(netdev);\r\n> >> +\tstruct hnae3_handle *h = priv->ae_handle;\r\n> >> +\tstruct hnae3_knic_private_info *kinfo = &h->kinfo;\r\n> >> +\tunsigned int queue_size = kinfo->rss_size * kinfo->num_tc;\r\n> >> +\tint ret;\r\n> >> +\r\n> >> +\tret = netif_set_real_num_tx_queues(netdev, queue_size);\r\n> >> +\tif (ret) {\r\n> >> +\t\tnetdev_err(netdev,\r\n> >> +\t\t\t \"netif_set_real_num_tx_queues fail, ret=%d!\\n\",\r\n> >> +\t\t\t ret);\r\n> >> +\t\treturn ret;\r\n> >> +\t}\r\n> >> +\r\n> >> +\tret = netif_set_real_num_rx_queues(netdev, queue_size);\r\n> >\r\n> > I don't think you're changing the driver behavior, but why are you setting\r\n> > the real number of rx queues based on the number of TCs?\r\n> > Do you actually open (TC x RSS) Rx queues?\r\n> >\r\n> > .\r\n> >","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=Mellanox.com header.i=@Mellanox.com\n\theader.b=\"ocF8Ak3S\"; dkim-atps=neutral","spf=none (sender IP is )\n\tsmtp.mailfrom=yuvalm@mellanox.com; "],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y1gHc6cF8z9tXn\n\tfor ;\n\tTue, 26 Sep 2017 22:29:16 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S967855AbdIZM3I (ORCPT );\n\tTue, 26 Sep 2017 08:29:08 -0400","from mail-he1eur01on0049.outbound.protection.outlook.com\n\t([104.47.0.49]:22869\n\t\"EHLO EUR01-HE1-obe.outbound.protection.outlook.com\"\n\trhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP\n\tid S967381AbdIZM3G (ORCPT );\n\tTue, 26 Sep 2017 08:29:06 -0400","from AM0PR0502MB3683.eurprd05.prod.outlook.com (52.133.46.152) by\n\tAM0PR0502MB3681.eurprd05.prod.outlook.com (52.133.46.150) with\n\tMicrosoft SMTP Server (version=TLS1_2,\n\tcipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id\n\t15.20.77.7; Tue, 26 Sep 2017 12:29:03 +0000","from AM0PR0502MB3683.eurprd05.prod.outlook.com\n\t([fe80::5cbd:456e:e0ba:bbde]) by\n\tAM0PR0502MB3683.eurprd05.prod.outlook.com\n\t([fe80::5cbd:456e:e0ba:bbde%13]) with mapi id 15.20.0077.011;\n\tTue, 26 Sep 2017 12:29:03 +0000"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com;\n\ts=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;\n\tbh=3nPZvLKUZ0N6zy4ziWy89JsUwULVIkNXSk9O4bxR3MI=;\n\tb=ocF8Ak3STKYR7+hkoj8LB9fCaKzQ/+sZPRGxFVEyK/gzCLQ9ouMJ+9xPjCbPXy7Tg2s8skPrADfYrImOAi+Opl5ei1wHPZ0qRsQ3CZn/izDsNBGe2dPrzM2uf88EmOK55PlLtxkfRSh3lWjNoYGmZ3KQJ2fDjCOvB+nRVns2/bU=","From":"Yuval Mintz ","To":"Yunsheng Lin ","CC":"\"huangdaode@hisilicon.com\" ,\n\t\"xuwei5@hisilicon.com\" ,\n\t\"liguozhu@hisilicon.com\" ,\n\t\"Yisen.Zhuang@huawei.com\" ,\n\t\"gabriele.paoloni@huawei.com\" ,\n\t\"john.garry@huawei.com\" ,\n\t\"linuxarm@huawei.com\" ,\n\t\"salil.mehta@huawei.com\" ,\n\t\"lipeng321@huawei.com\" ,\n\t\"netdev@vger.kernel.org\" ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\t\"davem@davemloft.net\" ","Subject":"RE: [PATCH v2 net-next 10/10] net: hns3: Add mqprio support when\n\tinteracting with network stack","Thread-Topic":"[PATCH v2 net-next 10/10] net: hns3: Add mqprio support when\n\tinteracting with network stack","Thread-Index":"AQHTNm760RsBmPn/P0qzMTftPnVtNaLGs2sggABJ5gCAABowoA==","Date":"Tue, 26 Sep 2017 12:29:02 +0000","Message-ID":"","References":"<1506392718-50463-1-git-send-email-linyunsheng@huawei.com>\n\t<1506392718-50463-11-git-send-email-linyunsheng@huawei.com>\n\t\n\t<3fe662df-a216-4966-863c-d98555ef3ed2@huawei.com>","In-Reply-To":"<3fe662df-a216-4966-863c-d98555ef3ed2@huawei.com>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","authentication-results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=Mellanox.com header.i=@Mellanox.com\n\theader.b=\"ocF8Ak3S\"; dkim-atps=neutral","spf=none (sender IP is )\n\tsmtp.mailfrom=yuvalm@mellanox.com; "],"x-originating-ip":"[193.47.165.251]","x-ms-publictraffictype":"Email","x-microsoft-exchange-diagnostics":"1; AM0PR0502MB3681;\n\t6:5Q8VEd+eGpk6iUAUQ/aFndy1NuqQa9uTe4LqslKa/p67MHo5KX3BYgMaJB7wngMArG+jiJUzUIhNqycm/42ZkVQNmEwbLGpZ0pQbw0BJbemiTOjZXg7gmRN6p73wxN+8cDEh83zQeKkwaRX6B6gDSBc+a6KJ6QmcGh28BVuqFvsotBCQhc5S6/qYmnatm4cKjTxtdLBCK9rY8eNRUGKuUDSfJVt63/ofVSUyHgtYMPZJoDRkUMCkvP6ON8IkmDdgjR7AkWOwyvnXPr5dC51bASEZAQfHAIYzTZn5S1p4BmhoNzRnmWswvyZl160wrzTUZvaDZraBe7KShAkjGUKbPA==;\n\t5:Bm3jLCbss25j6sFJEn1CrWhOptpgIDBFg8KCuNUHua9lfkamw9VtfTVp+pOwGZUULLg88iaI6mVoLMA7lUZY8z20NVTNwtIZzN/RZ9CKYLF+JsUD93bzJcuWut5CtlD7mhX+Fx/Wootgkn1XCsbkSg==;\n\t24:oln2gcGCrfZsksQEGmd06QeyR8R78WaoVnVZrYmEne1x12daBgD2J/HYbNmG8pm3V32GJtqlgWFipQu4+bnyW6JFxOIIfik3d2oiL9umb2I=;\n\t7:RfwnikoLrJalA+04pYxZ/FI2aDilo7efIU7GWK4ojpDsMvwncNphlvRSg5BephHSIhYGoLLGXvu81SuAlCCZHrjhRTwl/w6O50X1CPReW4TYvwGRIXhNbKL58hElshRgayytDuOr/cU9AkrRUdYzuKRezGbPc8MGhker+DCdg7RK6hGWNeaGCW1lzj3zIzT6dOzMx2LUrT36y8reMwOYNNja4+hb3LnFyFQNaSjhrKo=","x-ms-exchange-antispam-srfa-diagnostics":"SSOS;","x-ms-office365-filtering-correlation-id":"272956a5-15aa-4d4c-3055-08d504da2c07","x-ms-office365-filtering-ht":"Tenant","x-microsoft-antispam":"UriScan:; BCL:0; PCL:0;\n\tRULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075);\n\tSRVR:AM0PR0502MB3681; ","x-ms-traffictypediagnostic":"AM0PR0502MB3681:","x-exchange-antispam-report-test":"UriScan:(17755550239193);","x-microsoft-antispam-prvs":"","x-exchange-antispam-report-cfa-test":"BCL:0; PCL:0;\n\tRULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);\n\tSRVR:AM0PR0502MB3681; BCL:0; PCL:0;\n\tRULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);\n\tSRVR:AM0PR0502MB3681; ","x-forefront-prvs":"0442E569BC","x-forefront-antispam-report":"SFV:NSPM;\n\tSFS:(10009020)(6009001)(376002)(346002)(189002)(24454002)(199003)(33656002)(9686003)(66066001)(478600001)(105586002)(3660700001)(189998001)(50986999)(25786009)(2950100002)(3280700002)(229853002)(53546010)(5250100002)(6916009)(93886005)(86362001)(2900100001)(3846002)(97736004)(7416002)(6436002)(99286003)(55016002)(5660300001)(76176999)(14454004)(7696004)(106356001)(74316002)(68736007)(6116002)(54356999)(101416001)(305945005)(53936002)(6506006)(7736002)(54906003)(4326008)(81156014)(8936002)(81166006)(102836003)(6246003)(8676002)(2906002)(316002);\n\tDIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR0502MB3681;\n\tH:AM0PR0502MB3683.eurprd05.prod.outlook.com; FPR:; SPF:None;\n\tPTR:InfoNoRecords; MX:1; A:1; LANG:en; ","received-spf":"None (protection.outlook.com: mellanox.com does not designate\n\tpermitted sender hosts)","spamdiagnosticoutput":"1:99","spamdiagnosticmetadata":"NSPM","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","MIME-Version":"1.0","X-OriginatorOrg":"Mellanox.com","X-MS-Exchange-CrossTenant-originalarrivaltime":"26 Sep 2017 12:29:02.9593\n\t(UTC)","X-MS-Exchange-CrossTenant-fromentityheader":"Hosted","X-MS-Exchange-CrossTenant-id":"a652971c-7d2e-4d9b-a6a4-d149256f461b","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"AM0PR0502MB3681","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1775969,"web_url":"http://patchwork.ozlabs.org/comment/1775969/","msgid":"<7eb4e0c0-f60c-ed0d-d75f-8cd5d4bc437d@huawei.com>","list_archive_url":null,"date":"2017-09-27T00:51:44","subject":"Re: [PATCH v2 net-next 10/10] net: hns3: Add mqprio support when\n\tinteracting with network stack","submitter":{"id":71804,"url":"http://patchwork.ozlabs.org/api/people/71804/","name":"Yunsheng Lin","email":"linyunsheng@huawei.com"},"content":"Hi, Yuval\n\nOn 2017/9/26 20:29, Yuval Mintz wrote:\n>> Hi, Yuval\n>>\n>> On 2017/9/26 14:43, Yuval Mintz wrote:\n>>>> When using tc qdisc to configure DCB parameter, dcb_ops->setup_tc\n>>>> is used to tell hclge_dcb module to do the setup.\n>>>\n>>> While this might be a step in the right direction, this causes an inconsistency\n>>> in user experience - Some [well, most] vendors didn't allow the mqprio\n>>> priority mapping to affect DCB, instead relying on the dcbnl functionality\n>>> to control that configuration.\n>>>\n>>> A couple of options to consider:\n>>> - Perhaps said logic shouldn't be contained inside the driver but rather\n>>> in mqprio logic itself. I.e., rely on DCBNL functionality [if available] from\n>>> within mqprio and try changing the configuration.\n>>\n>> In net/dcb/dcbnl.c\n>> dcbnl_ieee_set already call dcbnl_ieee_notify to notify the user space\n>> configuration has changed, does this dcbnl_ieee_notify function do the\n>> job for us? I am not sure if lldpad has registered for this notifition.\n> \n> Not that familiar with the dcbnl calls; Shouldn't dcbnl_setall be called to\n> make the configuration apply [or is that only for ieee]?\n\ndcbnl_setall is for cee to make the configuration apply.\nieee does not have the apply operation.\n\n> Regardless, don't know if it makes sense to assume user-application would\n> fix the qdisc configuration by notification while dcbnl logic in kernel could have\n> done that instead.\n> \n>> As you suggested below, can we add a new TC_MQPRIO_HW_OFFLOAD_\n>> value to\n>> reflect that the configuration is needed to be changed by dcbnl_ieee_set\n>> (perhaps some other function) in dcbnl?\n>> Do you think it is feasible?\n> \n> Either I'm miseading your answer or we think of it from 2 opposite end.\n> I was thinking that the new offloaded flag would indicate to the underlying\n> driver that it's expected to offload the prio mapping [as part of DCB].\n> If the driver would be incapable of that it would refuse the offload.\n> User would then have to explicitly request that the qdisc offload.\n\n\nAdding a new offloaded flag to indicate that mqpri is using a hardware offload\nshared by dcbnl seems a good idea.\nAs I do not know how the idea go with other, I will drop the mqprio support in\nthis patch, and try to add the mqprio support as you suggested in the next\npatchset.\n\nThanks again for the lengthly reply.\n\n> \n>>\n>>\n>>> - Add a new TC_MQPRIO_HW_OFFLOAD_ value to explicitly reflect user\n>>> request to allow this configuration to affect DCB.\n>>>\n>>>> When using lldptool to configure DCB parameter, hclge_dcb module\n>>>> call the client_ops->setup_tc to tell network stack which queue\n>>>> and priority is using for specific tc.\n>>>\n>>> You're basically bypassing the mqprio logic.\n>>> Since you're configuring the prio->queue mapping from DCB flow,\n>>> you'll get an mqprio-like behavior [meaning a transmitted packet\n>>> would reach a transmission queue associated with its priority] even\n>>> if device wasn't grated with an mqprio qdisc.\n>>> Why should your user even use mqprio? What benefit does he get from it?\n>>>\n>>> ...\n>>>\n>>>> +static int hns3_nic_set_real_num_queue(struct net_device *netdev)\n>>>> +{\n>>>> +\tstruct hns3_nic_priv *priv = netdev_priv(netdev);\n>>>> +\tstruct hnae3_handle *h = priv->ae_handle;\n>>>> +\tstruct hnae3_knic_private_info *kinfo = &h->kinfo;\n>>>> +\tunsigned int queue_size = kinfo->rss_size * kinfo->num_tc;\n>>>> +\tint ret;\n>>>> +\n>>>> +\tret = netif_set_real_num_tx_queues(netdev, queue_size);\n>>>> +\tif (ret) {\n>>>> +\t\tnetdev_err(netdev,\n>>>> +\t\t\t \"netif_set_real_num_tx_queues fail, ret=%d!\\n\",\n>>>> +\t\t\t ret);\n>>>> +\t\treturn ret;\n>>>> +\t}\n>>>> +\n>>>> +\tret = netif_set_real_num_rx_queues(netdev, queue_size);\n>>>\n>>> I don't think you're changing the driver behavior, but why are you setting\n>>> the real number of rx queues based on the number of TCs?\n>>> Do you actually open (TC x RSS) Rx queues?\n>>>\n>>> .\n>>>\n>","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y1zmw4X3Pz9t4Z\n\tfor ;\n\tWed, 27 Sep 2017 10:52:16 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1032856AbdI0AwG (ORCPT );\n\tTue, 26 Sep 2017 20:52:06 -0400","from szxga05-in.huawei.com ([45.249.212.191]:7027 \"EHLO\n\tszxga05-in.huawei.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1030619AbdI0AwF (ORCPT\n\t); Tue, 26 Sep 2017 20:52:05 -0400","from 172.30.72.58 (EHLO DGGEMS410-HUB.china.huawei.com)\n\t([172.30.72.58])\n\tby dggrg05-dlp.huawei.com (MOS 4.4.6-GA FastPath queued)\n\twith ESMTP id DIC19305; Wed, 27 Sep 2017 08:51:56 +0800 (CST)","from [127.0.0.1] (10.74.191.121) by DGGEMS410-HUB.china.huawei.com\n\t(10.3.19.210) with Microsoft SMTP Server id 14.3.301.0;\n\tWed, 27 Sep 2017 08:51:45 +0800"],"Subject":"Re: [PATCH v2 net-next 10/10] net: hns3: Add mqprio support when\n\tinteracting with network stack","To":"Yuval Mintz ","CC":"\"huangdaode@hisilicon.com\" ,\n\t\"xuwei5@hisilicon.com\" ,\n\t\"liguozhu@hisilicon.com\" ,\n\t\"Yisen.Zhuang@huawei.com\" ,\n\t\"gabriele.paoloni@huawei.com\" ,\n\t\"john.garry@huawei.com\" ,\n\t\"linuxarm@huawei.com\" ,\n\t\"salil.mehta@huawei.com\" ,\n\t\"lipeng321@huawei.com\" ,\n\t\"netdev@vger.kernel.org\" ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\t\"davem@davemloft.net\" ","References":"<1506392718-50463-1-git-send-email-linyunsheng@huawei.com>\n\t<1506392718-50463-11-git-send-email-linyunsheng@huawei.com>\n\t\n\t<3fe662df-a216-4966-863c-d98555ef3ed2@huawei.com>\n\t","From":"Yunsheng Lin ","Message-ID":"<7eb4e0c0-f60c-ed0d-d75f-8cd5d4bc437d@huawei.com>","Date":"Wed, 27 Sep 2017 08:51:44 +0800","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=\"utf-8\"","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-Originating-IP":"[10.74.191.121]","X-CFilter-Loop":"Reflected","X-Mirapoint-Virus-RAPID-Raw":"score=unknown(0),\n\trefid=str=0001.0A0B0203.59CAF62D.0003, ss=1, re=0.000, recu=0.000,\n\treip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,\n\tso=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32","X-Mirapoint-Loop-Id":"c76adcc21de481378508f32c3decbe87","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}}]