From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id D4739426DE; Sat, 7 Oct 2023 10:36:42 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 710FB4029C; Sat, 7 Oct 2023 10:36:42 +0200 (CEST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by mails.dpdk.org (Postfix) with ESMTP id E09F040293 for ; Sat, 7 Oct 2023 10:36:40 +0200 (CEST) Received: from kwepemi500020.china.huawei.com (unknown [172.30.72.57]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4S2dpN5YrvzRhr4; Sat, 7 Oct 2023 16:32:44 +0800 (CST) Received: from [10.67.121.175] (10.67.121.175) by kwepemi500020.china.huawei.com (7.221.188.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Sat, 7 Oct 2023 16:36:37 +0800 Message-ID: <0e4b8a39-9c57-b645-4fc3-f80451481f7f@huawei.com> Date: Sat, 7 Oct 2023 16:36:37 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH v2 1/8] lib/ethdev: update Rx and Tx queue status To: Ferruh Yigit , "dev@dpdk.org" , Thomas Monjalon , Andrew Rybchenko CC: "lihuisong (C)" , David Marchand References: <20230908112901.1169869-1-haijie1@huawei.com> <20230928074305.2991100-1-haijie1@huawei.com> <20230928074305.2991100-2-haijie1@huawei.com> From: Jie Hai In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.121.175] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To kwepemi500020.china.huawei.com (7.221.188.8) X-CFilter-Loop: Reflected X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On 2023/9/28 21:15, Ferruh Yigit wrote: > On 9/28/2023 8:42 AM, Jie Hai wrote: >> The DPDK framework reports the queue status, which is stored in >> 'dev->data->tx_queue_state' and 'dev->data->rx_queue_state'.The >> state is currently maintained by the drivers. Users may determine >> whether a queue participates in packet forwarding based on the >> state. However, not all drivers correctly report the queue status. >> This may cause forwarding problems. >> >> Since it is difficult to modify the queue status of all drivers, >> we consider updating the queue status at the framework level. >> Some drivers support queues for hairpin, leaving status updating >> for such queues to the drivers. Some drivers support >> 'deferred_start'. Assume that all drivers that support >> 'deferred_start' can obtain the configuration through >> 'rte_eth_tx_queue_info_get' and 'rte_eth_rx_queue_info_get'. So >> we can directly update the queue status in 'rte_eth_dev_start' >> and 'rte_eth_dev_stop'. >> >> Signed-off-by: Jie Hai >> --- >> lib/ethdev/rte_ethdev.c | 40 ++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 40 insertions(+) >> >> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c >> index 0840d2b5942a..e3aaa71eba9e 100644 >> --- a/lib/ethdev/rte_ethdev.c >> +++ b/lib/ethdev/rte_ethdev.c >> @@ -1641,6 +1641,9 @@ rte_eth_dev_start(uint16_t port_id) >> struct rte_eth_dev_info dev_info; >> int diag; >> int ret, ret_stop; >> + uint16_t i; >> + struct rte_eth_rxq_info rxq_info; >> + struct rte_eth_txq_info txq_info; >> >> RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV); >> dev = &rte_eth_devices[port_id]; >> @@ -1697,6 +1700,30 @@ rte_eth_dev_start(uint16_t port_id) >> (*dev->dev_ops->link_update)(dev, 0); >> } >> >> + for (i = 0; i < dev->data->nb_rx_queues; i++) { >> + if (rte_eth_dev_is_rx_hairpin_queue(dev, i)) >> + continue; >> + >> + memset(&rxq_info, 0, sizeof(rxq_info)); >> + ret = rte_eth_rx_queue_info_get(port_id, i, &rxq_info); >> + if (ret == 0 && rxq_info.conf.rx_deferred_start != 0) >> + dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED; >> + else >> + dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED; >> + } >> + >> + for (i = 0; i < dev->data->nb_tx_queues; i++) { >> + if (rte_eth_dev_is_tx_hairpin_queue(dev, i)) >> + continue; >> + >> + memset(&txq_info, 0, sizeof(txq_info)); >> + ret = rte_eth_tx_queue_info_get(port_id, i, &txq_info); >> + if (ret == 0 && txq_info.conf.tx_deferred_start != 0) >> + dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED; >> + else >> + dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED; >> + } >> + > > Hi Jie, > > I am not sure about adding queue_info_get() calls a dependency to > start(), since start() is a mandatory API, I am concerned about possible > side affects. > Like if rte_eth_rx_queue_info_get() fails,Yes, unless we let rte_eth_rx|tx_queue_info_get a mandatory API. > Or event though deferred_start is set, can application first call > rx_queue_start(), later start(), like: > start() > rx_queue_start() > stop() > rx_queue_start() > start() start() --> deferred_start is confugured, the queue is stopped rx_queue_start() --> the queue is started stop() --> all queues are stopped rx_queue_start() --> not supported, port should starts first start() If we change the order as: start() rx_queue_start() stop() start() The last status of the queue for different drivers may be different. Most drivers starts all queues except the queue setting deferred_start. For sfc driver, all queues are started and the status of the queue setting deferred_start will be reported as stopped, which is not correct. That's the point, drivers have their own private processing for different sequences of deferred_start, start|stop and queue_start|stop. > Or even applications sets deferred_start, PMD be ignoring without > reflecting that to conf.rx_deferred_start, etc... Supppose the app sets the deferred_start, whether the driver verifies the support the configuration or not, whether the driver issues the configuration to the hardware or not, whether the driver saves and reports the configuration or not, Different driver implementations vary. For the above three cases, pay attention to the following: 1) Y-Y-Y That's what we need. 2) Y-Y-N That's what we should add. 3) N-N-Y This will lead to wrong information(e.g.ice_rxtx.c mlx5_txq.c mlx5_rxq.c) 4) N-N-N That's what we need, too. > > > Anyway, intention was to move common task, setting queue state, to the > ethdev layer, but because of the deferred_start, in rte_eth_dev_start() > we don't really know the queue state. > > We can try to move deferred state information to the ethdev, but that is > similar to setting queue state in the driver, that is why perhaps better > to leave setting state to drivers, as done in the first version of the set. > @Jie, @David, what do you think? > I support V1. Whoever changes the queue status is responsible for reporting the queue status. That will maintains the specificity of the drive treatment. > > And, @Jie, can you also check the rx_queue_start() & tx_queue_start() > dev_ops of the drivers sets the queue state? > If missing on some drivers, that needs to be added too. > I have checked already, all drivers support rx_queue_start() & tx_queue_start() set the queue state. > >> /* expose selection of PMD fast-path functions */ >> eth_dev_fp_ops_setup(rte_eth_fp_ops + port_id, dev); >> >> @@ -1708,6 +1735,7 @@ int >> rte_eth_dev_stop(uint16_t port_id) >> { >> struct rte_eth_dev *dev; >> + uint16_t i; >> int ret; >> >> RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV); >> @@ -1731,6 +1759,18 @@ rte_eth_dev_stop(uint16_t port_id) >> dev->data->dev_started = 0; >> rte_ethdev_trace_stop(port_id, ret); >> >> + for (i = 0; i < dev->data->nb_rx_queues; i++) { >> + if (rte_eth_dev_is_rx_hairpin_queue(dev, i)) >> + continue; >> + dev->data->rx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED; >> + } >> + >> + for (i = 0; i < dev->data->nb_tx_queues; i++) { >> + if (rte_eth_dev_is_tx_hairpin_queue(dev, i)) >> + continue; >> + dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STOPPED; >> + } >> + >> return ret; >> } >> >