From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966832AbdIZHdt (ORCPT ); Tue, 26 Sep 2017 03:33:49 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:7020 "EHLO szxga05-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935108AbdIZHdq (ORCPT ); Tue, 26 Sep 2017 03:33:46 -0400 Subject: Re: [PATCH v2 net-next 10/10] net: hns3: Add mqprio support when interacting with network stack To: Yuval Mintz CC: "huangdaode@hisilicon.com" , "xuwei5@hisilicon.com" , "liguozhu@hisilicon.com" , "Yisen.Zhuang@huawei.com" , "gabriele.paoloni@huawei.com" , "john.garry@huawei.com" , "linuxarm@huawei.com" , "salil.mehta@huawei.com" , "lipeng321@huawei.com" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "davem@davemloft.net" References: <1506392718-50463-1-git-send-email-linyunsheng@huawei.com> <1506392718-50463-11-git-send-email-linyunsheng@huawei.com> 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 Thunderbird/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), refid=str=0001.0A090204.59CA02D0.0062,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c76adcc21de481378508f32c3decbe87 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Yuval On 2017/9/26 14:43, Yuval Mintz wrote: >> When using tc qdisc to configure DCB parameter, dcb_ops->setup_tc >> is used to tell hclge_dcb module to do the setup. > > While this might be a step in the right direction, this causes an inconsistency > in user experience - Some [well, most] vendors didn't allow the mqprio > priority mapping to affect DCB, instead relying on the dcbnl functionality > to control that configuration. > > A couple of options to consider: > - Perhaps said logic shouldn't be contained inside the driver but rather > in mqprio logic itself. I.e., rely on DCBNL functionality [if available] from > within mqprio and try changing the configuration. > - Add a new TC_MQPRIO_HW_OFFLOAD_ value to explicitly reflect user > request to allow this configuration to affect DCB. > >> When using lldptool to configure DCB parameter, hclge_dcb module >> call the client_ops->setup_tc to tell network stack which queue >> and priority is using for specific tc. > > You're basically bypassing the mqprio logic. > Since you're configuring the prio->queue mapping from DCB flow, > you'll get an mqprio-like behavior [meaning a transmitted packet > would reach a transmission queue associated with its priority] even > if device wasn't grated with an mqprio qdisc. > Why should your user even use mqprio? What benefit does he get from it? > > ... > >> +static int hns3_nic_set_real_num_queue(struct net_device *netdev) >> +{ >> + struct hns3_nic_priv *priv = netdev_priv(netdev); >> + struct hnae3_handle *h = priv->ae_handle; >> + struct hnae3_knic_private_info *kinfo = &h->kinfo; >> + unsigned int queue_size = kinfo->rss_size * kinfo->num_tc; >> + int ret; >> + >> + ret = netif_set_real_num_tx_queues(netdev, queue_size); >> + if (ret) { >> + netdev_err(netdev, >> + "netif_set_real_num_tx_queues fail, ret=%d!\n", >> + ret); >> + return ret; >> + } >> + >> + ret = netif_set_real_num_rx_queues(netdev, queue_size); > > I don't think you're changing the driver behavior, but why are you setting > the real number of rx queues based on the number of TCs? > Do you actually open (TC x RSS) Rx queues? Yes, our hardware can do the rss based on TC. Sorry for almost forget to answer this question. Thanks for your time reviewing again. > > . >