From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id E967242611;
Fri, 22 Sep 2023 04:41:32 +0200 (CEST)
Received: from mails.dpdk.org (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id C230040265;
Fri, 22 Sep 2023 04:41:32 +0200 (CEST)
Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255])
by mails.dpdk.org (Postfix) with ESMTP id 490FF40151
for <dev@dpdk.org>; Fri, 22 Sep 2023 04:41:31 +0200 (CEST)
Received: from kwepemi500020.china.huawei.com (unknown [172.30.72.53])
by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4RsGgX02kcz15NPh;
Fri, 22 Sep 2023 10:39:19 +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; Fri, 22 Sep 2023 10:41:27 +0800
Message-ID: <ad070ad3-cf66-ef1b-e3df-b499a9a28257@huawei.com>
Date: Fri, 22 Sep 2023 10:41:27 +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 00/36] fix Rx and Tx queue state
To: Ferruh Yigit <ferruh.yigit@amd.com>, David Marchand
<david.marchand@redhat.com>
CC: <dev@dpdk.org>, <lihuisong@huawei.com>, Thomas Monjalon
<thomas@monjalon.net>
References: <20230908112901.1169869-1-haijie1@huawei.com>
<CAJFAV8weGmfS_F+K6JP=d_MhJgudVhF+LGtYXhv8TFprZw_VMw@mail.gmail.com>
<6c030892-5e27-4537-9262-c733914d95df@amd.com>
From: Jie Hai <haijie1@huawei.com>
In-Reply-To: <6c030892-5e27-4537-9262-c733914d95df@amd.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.67.121.175]
X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) 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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
On 2023/9/19 0:54, Ferruh Yigit wrote:
> On 9/8/2023 12:50 PM, David Marchand wrote:
>> On Fri, Sep 8, 2023 at 1:32 PM Jie Hai <haijie1@huawei.com> wrote:
>>>
>>> The DPDK framework reports the queue state, which is stored in
>>> dev->data->tx_queue_state and dev->data->rx_queue_state. The
>>> state is maintained by the driver. Users may determine whether
>>> a queue participates in packet forwarding based on the state,
>>> for example,
>>
>> The driver is maintaining this state in dev_start / dev_stop and per
>> queue start/stop handlers.
>>
>>>
>>> [1] 5028f207a4fa ("app/testpmd: fix secondary process packet forwarding"
>>> [2] 141a520b35f7 ("app/testpmd: fix primary process not polling all queues")
>>>
>>> Therefore, the drivers need to modify the queue state in time
>>> according to the actual situation, especially when dev_start
>>> and dev_stop are called. see [3] for more information.
>>>
>>> [3] https://inbox.dpdk.org/dev/20230721160422.3848154-1-ferruh.yigit@amd.com/
>>>
>>> This patchset also resubmit the patch [2] and makes some fixes on the patch.
>>
>> I just had a quick look at some patches and I wonder if a better fix
>> would be at the ethdev level, rather than fixing all drivers.
>>
>>
>
> I came here to make the same comment,
>
> Jie, I forgot if we discuss this already but,
>
> does it work if we update queue state in 'rte_eth_dev_start()' &
> 'rte_eth_dev_stop()' when 'dev_start' & 'dev_stop' dev_ops succeeds?
>
> This solves the case driver forgets to update the queue state.
>
>
Hi, Furrh and David,
It's OK for dev_stop, but not enough for dev_start.
Some drivers also support deferred_start.
Therefore, not all queues are in the start state after dev_start.
If we want to get that correct queue state at the framework level, I
offer the following options:
step 1. A capability(e.g. RTE_ETH_DEV_CAPA_DEFERRED_START) is added to
the framework, indicating whether the driver supports deferred_start.
The capability should be reported by the driver and user can get it by
rte_eth_dev_info_get().
step 2. All drivers that support deferred_start should report configuration
information about deferred_start through
rte_eth_rx_queue_info_get |rte_eth_tx_queue_info_get.
step 3.The framework updates the queue status based on the support and
configuration of deferred_start.
Is this solution OK?
> .