From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id 8CC4EA490 for ; Mon, 15 Jan 2018 08:25:29 +0100 (CET) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1-us4.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 27F99BC0053; Mon, 15 Jan 2018 07:25:28 +0000 (UTC) Received: from [192.168.38.17] (84.52.114.114) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 15 Jan 2018 07:25:21 +0000 To: Qi Zhang , CC: , , References: <20180115015729.10181-1-qi.z.zhang@intel.com> From: Andrew Rybchenko Message-ID: <328737a6-89d9-7285-81ec-8a9bd2dfe693@solarflare.com> Date: Mon, 15 Jan 2018 10:25:17 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180115015729.10181-1-qi.z.zhang@intel.com> Content-Language: en-GB X-Originating-IP: [84.52.114.114] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-11.0.0.1191-8.100.1062-23596.003 X-TM-AS-Result: No--10.371400-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-MDID: 1516001128-h1RqZXE-fAjp Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [RFC] ether: support deferred queue setup 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: , X-List-Received-Date: Mon, 15 Jan 2018 07:25:30 -0000 On 01/15/2018 04:57 AM, Qi Zhang wrote: > According to exist implementation, rte_eth_[rx|tx]_queue_setup will > always return fail if device is already started(rte_eth_dev_start). > > This can't satisfied the usage when application want to deferred setup > part of the queues while keep traffic running on those queues already > be setup. > > example: > rte_eth_dev_config(nb_rxq = 2, nb_txq =2) > rte_eth_rx_queue_setup(idx = 0 ...) > rte_eth_rx_queue_setup(idx = 0 ...) > rte_eth_dev_start(...) /* [rx|tx]_burst is ready to start on queue 0 */ > rte_eth_rx_queue_setup(idx=1 ...) /* fail*/ > > Basically this is not a general hardware limitation, because for NIC like > i40e, ixgbe, it is not necessary to stop the whole device before configure > a fresh queue or reconfigure an exist queue with traffic on it. > > The patch add new eth_dev_ops: [rx|tx]_queue_hot_[setup|release] and > internal logic of rte_eth_[rx|tx]_queue_setup is changed, so application > is allowed to setup queue after device start if the driver is implemented > properly. I see no point to introduce a new eth_dev_ops. It is possible to simply allow setup/release operations when the device is started. If it is desirable to make it controllable and have checks in generic code, it is possible to have capability bits in dev_info to say that device supports hot setup/release of Tx/Rx queues. > The typical implementation of [rx|tx]_queue_hot_setup could be: > 1. do the same thing in [rx|tx]_queue_setup. > 2. perform per queue start logic from [rx|tx]_queue_start. > > The typical implementation of [rx|tx]_queue_hot_release could be: > 1. perform per queue stop logic from [rx|tx]_queue_stop. > 2. do the same thing in [rx|tx]_queue_release. > > Signed-off-by: Qi Zhang > --- > lib/librte_ether/rte_ethdev.c | 54 ++++++++++++++++++++++++------------------- > lib/librte_ether/rte_ethdev.h | 8 +++++++ > 2 files changed, 38 insertions(+), 24 deletions(-) <...>