From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 128772BD7 for ; Tue, 22 Mar 2016 11:33:48 +0100 (CET) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga103.jf.intel.com with ESMTP; 22 Mar 2016 03:33:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,376,1455004800"; d="scan'208";a="71003346" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by fmsmga004.fm.intel.com with ESMTP; 22 Mar 2016 03:33:33 -0700 Received: from irsmsx106.ger.corp.intel.com ([169.254.8.172]) by IRSMSX102.ger.corp.intel.com ([169.254.2.19]) with mapi id 14.03.0248.002; Tue, 22 Mar 2016 10:33:32 +0000 From: "Loftus, Ciara" To: Tetsuya Mukawa , "dev@dpdk.org" CC: "Richardson, Bruce" , "ann.zhuangyanying@huawei.com" , "thomas.monjalon@6wind.com" Thread-Topic: [dpdk-dev] [PATCH v13 2/2] vhost: Add VHOST PMD Thread-Index: AQHRgzT9Aj3Q6EJvQUG1+t8Gi263BZ9kAaZQgACzooCAAA9gAIAAfCsA Date: Tue, 22 Mar 2016 10:33:31 +0000 Message-ID: <74F120C019F4A64C9B78E802F6AD4CC24F847885@IRSMSX106.ger.corp.intel.com> References: <1458030701-11487-3-git-send-email-mukawa@igel.co.jp> <1458539108-15686-3-git-send-email-mukawa@igel.co.jp> <74F120C019F4A64C9B78E802F6AD4CC24F84543E@IRSMSX106.ger.corp.intel.com> <56F0A5F7.2090205@igel.co.jp> <56F0B2DC.3010602@igel.co.jp> In-Reply-To: <56F0B2DC.3010602@igel.co.jp> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNTU1ZTlhYTMtYTM5OS00MWNlLWFhYzUtODY3YjQwNDU3MmU0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IlFyNnRmQjZ6TEdKd2tJMG51ODJCamM5SW1CVEtGdjMxeGVTUlMrb29Ta1k9In0= x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v13 2/2] vhost: Add VHOST PMD X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 10:33:49 -0000 >=20 > On 2016/03/22 10:55, Tetsuya Mukawa wrote: > > On 2016/03/22 0:40, Loftus, Ciara wrote: > >>> + > >>> +static void > >>> +eth_dev_info(struct rte_eth_dev *dev, > >>> + struct rte_eth_dev_info *dev_info) > >>> +{ > >>> + dev_info->driver_name =3D drivername; > >>> + dev_info->max_mac_addrs =3D 1; > >>> + dev_info->max_rx_pktlen =3D (uint32_t)-1; > >>> + dev_info->max_rx_queues =3D dev->data->nb_rx_queues; > >>> + dev_info->max_tx_queues =3D dev->data->nb_tx_queues; > >> I'm not entirely familiar with eth driver code so please correct me if= I am > wrong. > >> > >> I'm wondering if assigning the max queue values to dev->data- > >nb_*x_queues is correct. > >> A user could change the value of nb_*x_queues with a call to > rte_eth_dev_configure(n_queues) which in turn calls > rte_eth_dev_*x_queue_config(n_queues) which will set dev->data- > >nb_*x_queues to the value of n_queues which can be arbitrary and > decided by the user. If this is the case, dev->data->nb_*x_queues will no > longer reflect the max, rather the value the user chose in the call to > rte_eth_dev_configure. And the max could potentially change with multiple > calls to configure. Is this intended behaviour? > > Hi Ciara, > > > > Thanks for reviewing it. Here is a part of rte_eth_dev_configure(). > > > > int > > rte_eth_dev_configure(uint8_t port_id, uint16_t nb_rx_q, uint16_t > nb_tx_q, > > const struct rte_eth_conf *dev_conf) > > { > > > > /* > > * Check that the numbers of RX and TX queues are not greater > > * than the maximum number of RX and TX queues supported by the > > * configured device. > > */ > > (*dev->dev_ops->dev_infos_get)(dev, &dev_info); > > > > if (nb_rx_q =3D=3D 0 && nb_tx_q =3D=3D 0) { > > > > return -EINVAL; > > } > > > > if (nb_rx_q > dev_info.max_rx_queues) { > > > > return -EINVAL; > > } > > > > if (nb_tx_q > dev_info.max_tx_queues) { > > > > return -EINVAL; > > } > > > > > > > > /* > > * Setup new number of RX/TX queues and reconfigure device. > > */ > > diag =3D rte_eth_dev_rx_queue_config(dev, nb_rx_q); > > > > diag =3D rte_eth_dev_tx_queue_config(dev, nb_tx_q); > > > > } > > > > Anyway, rte_eth_dev_tx/rx_queue_config() will be called only after > > checking the current maximum number of queues. > > So the user cannot set the number of queues greater than current > maximum > > number. > > > > Regards, > > Tetsuya >=20 > Hi Ciara, >=20 > Now, I understand what you say. > Probably you pointed out the case that the user specified a value > smaller than current maximum value. >=20 > For example, if we have 4 queues. Below code will be failed at last line. > rte_eth_dev_configure(portid, 4, 4, ...); > rte_eth_dev_configure(portid, 2, 2, ...); > rte_eth_dev_configure(portid, 4, 4, ...); >=20 > I will submit a patch to fix it. Could you please review and ack it? Hi Tetsuya, Correct, sorry for the initial confusion. Thanks for the patch so quickly. I've reviewed the code - looks good. I just want to run some tests and will= give my Ack later today all going well. Thanks, Ciara >=20 > Regards, > Tetsuya