Message ID | 20230908112901.1169869-1-haijie1@huawei.com (mailing list archive) |
---|---|
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id B4EBF42547; Fri, 8 Sep 2023 13:32:15 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9FAA0402AF; Fri, 8 Sep 2023 13:32:15 +0200 (CEST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by mails.dpdk.org (Postfix) with ESMTP id 1396340042 for <dev@dpdk.org>; Fri, 8 Sep 2023 13:32:13 +0200 (CEST) Received: from kwepemi500020.china.huawei.com (unknown [172.30.72.55]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4Rhv6h0TwCzrSSW for <dev@dpdk.org>; Fri, 8 Sep 2023 19:30:20 +0800 (CST) Received: from localhost.localdomain (10.67.165.2) 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, 8 Sep 2023 19:32:10 +0800 From: Jie Hai <haijie1@huawei.com> To: <dev@dpdk.org> CC: <haijie1@huawei.com>, <lihuisong@huawei.com> Subject: [PATCH 00/36] fix Rx and Tx queue state Date: Fri, 8 Sep 2023 19:28:25 +0800 Message-ID: <20230908112901.1169869-1-haijie1@huawei.com> X-Mailer: git-send-email 2.30.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.67.165.2] 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 <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 |
Series |
fix Rx and Tx queue state
|
|
Message
Jie Hai
Sept. 8, 2023, 11:28 a.m. UTC
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, [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. Jie Hai (36): net/axgbe: fix Rx and Tx queue state net/af_packet: fix Rx and Tx queue state net/af_xdp: fix Rx and Tx queue state net/avp: fix Rx and Tx queue state net/bnx2x: fix Rx and Tx queue state net/bnxt: fix Rx and Tx queue state net/bonding: fix Rx and Tx queue state net/cxgbe: fix Rx and Tx queue state net/dpaa: fix Rx and Tx queue state net/dpaa2: fix Rx and Tx queue state net/e1000: fix Rx and Tx queue state net/ena: fix Rx and Tx queue state net/enetc: fix Rx and Tx queue state net/enic: fix Rx and Tx queue state net/hinic: fix Rx and Tx queue state net/ipn3ke: fix Rx and Tx queue state net/memif: fix Rx and Tx queue state net/mana: fix Rx and Tx queue state net/mlx4: fix Rx and Tx queue state net/mvneta: fix Rx and Tx queue state net/mvpp2: fix Rx and Tx queue state net/netvsc: fix Rx and Tx queue state net/nfp: fix Rx and Tx queue state net/ngbe: fix Rx and Tx queue state net/null: fix Rx and Tx queue state net/octeon_ep: fix Rx and Tx queue state net/octeontx: fix Rx and Tx queue state net/pfe: fix Rx and Tx queue state net/ring: fix Rx and Tx queue state net/sfc: fix Rx and Tx queue state net/softnic: fix Rx and Tx queue state net/txgbe: fix Rx and Tx queue state net/vhost: fix Rx and Tx queue state net/virtio: fix Rx and Tx queue state net/vmxnet3: fix Rx and Tx queue state app/testpmd: fix primary process not polling all queues app/test-pmd/testpmd.c | 25 +++++++++++++++---- drivers/net/af_packet/rte_eth_af_packet.c | 9 +++++++ drivers/net/af_xdp/rte_eth_af_xdp.c | 13 ++++++++++ drivers/net/avp/avp_ethdev.c | 12 +++++++++ drivers/net/axgbe/axgbe_ethdev.c | 7 ++++++ drivers/net/axgbe/axgbe_rxtx.c | 2 ++ drivers/net/bnx2x/bnx2x_ethdev.c | 12 +++++++++ drivers/net/bnxt/bnxt_ethdev.c | 6 +++++ drivers/net/bonding/rte_eth_bond_pmd.c | 10 ++++++++ drivers/net/cxgbe/cxgbe_ethdev.c | 6 +++++ drivers/net/dpaa/dpaa_ethdev.c | 12 +++++++++ drivers/net/dpaa2/dpaa2_ethdev.c | 11 ++++++++ drivers/net/e1000/em_rxtx.c | 8 ++++++ drivers/net/e1000/igb_rxtx.c | 4 +++ drivers/net/ena/ena_ethdev.c | 12 +++++++++ drivers/net/enetc/enetc_ethdev.c | 12 +++++++++ drivers/net/enic/enic_ethdev.c | 6 +++++ drivers/net/hinic/hinic_pmd_ethdev.c | 12 +++++++++ drivers/net/ipn3ke/ipn3ke_representor.c | 12 +++++++++ drivers/net/mana/rx.c | 3 +++ drivers/net/mana/tx.c | 4 +++ drivers/net/memif/rte_eth_memif.c | 16 ++++++++++++ drivers/net/mlx4/mlx4.c | 13 ++++++++++ drivers/net/mvneta/mvneta_ethdev.c | 12 +++++++++ drivers/net/mvpp2/mrvl_ethdev.c | 10 ++++++++ drivers/net/netvsc/hn_ethdev.c | 12 +++++++++ drivers/net/nfp/flower/nfp_flower.c | 8 ++++++ .../net/nfp/flower/nfp_flower_representor.c | 12 +++++++++ drivers/net/nfp/nfp_common.c | 2 ++ drivers/net/nfp/nfp_ethdev.c | 6 +++++ drivers/net/nfp/nfp_ethdev_vf.c | 6 +++++ drivers/net/ngbe/ngbe_rxtx.c | 2 ++ drivers/net/null/rte_eth_null.c | 15 +++++++++++ drivers/net/octeon_ep/otx_ep_ethdev.c | 11 ++++++++ drivers/net/octeontx/octeontx_ethdev.c | 11 ++++++++ drivers/net/pfe/pfe_ethdev.c | 11 ++++++++ drivers/net/ring/rte_eth_ring.c | 15 +++++++++++ drivers/net/sfc/sfc_repr.c | 12 +++++++++ drivers/net/softnic/rte_eth_softnic.c | 12 +++++++++ drivers/net/txgbe/txgbe_rxtx.c | 8 ++++++ drivers/net/vhost/rte_eth_vhost.c | 12 +++++++++ drivers/net/virtio/virtio_ethdev.c | 11 ++++++++ drivers/net/vmxnet3/vmxnet3_ethdev.c | 12 +++++++++ 43 files changed, 422 insertions(+), 5 deletions(-)
Comments
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.
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.
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? > .
Hello, On Fri, Sep 22, 2023 at 4:41 AM Jie Hai <haijie1@huawei.com> wrote: > 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. rte_eth_dev_start must only update the queue state if rx_deferred_start is unset (see struct rte_eth_rxconf::rx_deferred_start). And the queue state needs to be updated in ethdev rte_eth_dev_rx_queue_start/stop. So I don't see where we need a new capability.
On 2023/9/22 14:41, David Marchand wrote: > Hello, > > On Fri, Sep 22, 2023 at 4:41 AM Jie Hai <haijie1@huawei.com> wrote: >> 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. > > rte_eth_dev_start must only update the queue state if > rx_deferred_start is unset (see struct > rte_eth_rxconf::rx_deferred_start). > And the queue state needs to be updated in ethdev > rte_eth_dev_rx_queue_start/stop. > > So I don't see where we need a new capability. > Hi, David, Thanks and you are right. The driver reports whether the queue is configured with deferred_start through rxq_info_get & rxq_info_get ops. The framework can obtain queue configuration through rte_eth_rx_queue_info_get & rte_eth_tx_queue_info_get. According to your suggestion, the prerequisite is that all drivers that support deferred_start support rxq_info_get & rxq_info_get ops reporting it. Currently, not all drivers support reporting the deferred_start configuration. Therefore, we need to modify some driver. I'll send V2 after finishing. Best, regards Jie Hai >
On 9/22/2023 7:41 AM, David Marchand wrote: > Hello, > > On Fri, Sep 22, 2023 at 4:41 AM Jie Hai <haijie1@huawei.com> wrote: >> 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. > > rte_eth_dev_start must only update the queue state if > rx_deferred_start is unset (see struct > rte_eth_rxconf::rx_deferred_start). > And the queue state needs to be updated in ethdev > rte_eth_dev_rx_queue_start/stop. > > So I don't see where we need a new capability. > > Hi David, Problem seems 'rte_eth_rxconf::rx_deferred_start' is not stored in ethdev level, so rte_eth_dev_start() can't use it. And although application can request it, via rxconf, it is not clear if driver supports it or if it will take into account, that is where a capability flag can be useful, but it is a big change for this patch.
On 9/8/2023 12:28 PM, Jie Hai 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, > > [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. > > Jie Hai (36): > net/axgbe: fix Rx and Tx queue state > net/af_packet: fix Rx and Tx queue state > net/af_xdp: fix Rx and Tx queue state > net/avp: fix Rx and Tx queue state > net/bnx2x: fix Rx and Tx queue state > net/bnxt: fix Rx and Tx queue state > net/bonding: fix Rx and Tx queue state > net/cxgbe: fix Rx and Tx queue state > net/dpaa: fix Rx and Tx queue state > net/dpaa2: fix Rx and Tx queue state > net/e1000: fix Rx and Tx queue state > net/ena: fix Rx and Tx queue state > net/enetc: fix Rx and Tx queue state > net/enic: fix Rx and Tx queue state > net/hinic: fix Rx and Tx queue state > net/ipn3ke: fix Rx and Tx queue state > net/memif: fix Rx and Tx queue state > net/mana: fix Rx and Tx queue state > net/mlx4: fix Rx and Tx queue state > net/mvneta: fix Rx and Tx queue state > net/mvpp2: fix Rx and Tx queue state > net/netvsc: fix Rx and Tx queue state > net/nfp: fix Rx and Tx queue state > net/ngbe: fix Rx and Tx queue state > net/null: fix Rx and Tx queue state > net/octeon_ep: fix Rx and Tx queue state > net/octeontx: fix Rx and Tx queue state > net/pfe: fix Rx and Tx queue state > net/ring: fix Rx and Tx queue state > net/sfc: fix Rx and Tx queue state > net/softnic: fix Rx and Tx queue state > net/txgbe: fix Rx and Tx queue state > net/vhost: fix Rx and Tx queue state > net/virtio: fix Rx and Tx queue state > net/vmxnet3: fix Rx and Tx queue state > app/testpmd: fix primary process not polling all queues > For series, Acked-by: Ferruh Yigit <ferruh.yigit@amd.com> Except net/mana (it has separate patch by its maintainer), Series applied to dpdk-next-net/main, thanks.
On 10/16/2023 12:51 PM, Ferruh Yigit wrote: > On 9/8/2023 12:28 PM, Jie Hai 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, >> >> [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. >> >> Jie Hai (36): >> net/axgbe: fix Rx and Tx queue state >> net/af_packet: fix Rx and Tx queue state >> net/af_xdp: fix Rx and Tx queue state >> net/avp: fix Rx and Tx queue state >> net/bnx2x: fix Rx and Tx queue state >> net/bnxt: fix Rx and Tx queue state >> net/bonding: fix Rx and Tx queue state >> net/cxgbe: fix Rx and Tx queue state >> net/dpaa: fix Rx and Tx queue state >> net/dpaa2: fix Rx and Tx queue state >> net/e1000: fix Rx and Tx queue state >> net/ena: fix Rx and Tx queue state >> net/enetc: fix Rx and Tx queue state >> net/enic: fix Rx and Tx queue state >> net/hinic: fix Rx and Tx queue state >> net/ipn3ke: fix Rx and Tx queue state >> net/memif: fix Rx and Tx queue state >> net/mana: fix Rx and Tx queue state >> net/mlx4: fix Rx and Tx queue state >> net/mvneta: fix Rx and Tx queue state >> net/mvpp2: fix Rx and Tx queue state >> net/netvsc: fix Rx and Tx queue state >> net/nfp: fix Rx and Tx queue state >> net/ngbe: fix Rx and Tx queue state >> net/null: fix Rx and Tx queue state >> net/octeon_ep: fix Rx and Tx queue state >> net/octeontx: fix Rx and Tx queue state >> net/pfe: fix Rx and Tx queue state >> net/ring: fix Rx and Tx queue state >> net/sfc: fix Rx and Tx queue state >> net/softnic: fix Rx and Tx queue state >> net/txgbe: fix Rx and Tx queue state >> net/vhost: fix Rx and Tx queue state >> net/virtio: fix Rx and Tx queue state >> net/vmxnet3: fix Rx and Tx queue state >> app/testpmd: fix primary process not polling all queues >> > > For series, > Acked-by: Ferruh Yigit <ferruh.yigit@amd.com> > > > Except net/mana (it has separate patch by its maintainer), > Series applied to dpdk-next-net/main, thanks. > net/netvsc also dropped from this set and maintainer version [1] merged. [1] https://patchwork.dpdk.org/project/dpdk/patch/1693333769-10296-1-git-send-email-longli@linuxonhyperv.com/
16/10/2023 13:51, Ferruh Yigit: > On 9/8/2023 12:28 PM, Jie Hai 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, > > > > [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. > > > > Jie Hai (36): > > net/axgbe: fix Rx and Tx queue state > > net/af_packet: fix Rx and Tx queue state > > net/af_xdp: fix Rx and Tx queue state > > net/avp: fix Rx and Tx queue state > > net/bnx2x: fix Rx and Tx queue state > > net/bnxt: fix Rx and Tx queue state > > net/bonding: fix Rx and Tx queue state > > net/cxgbe: fix Rx and Tx queue state > > net/dpaa: fix Rx and Tx queue state > > net/dpaa2: fix Rx and Tx queue state > > net/e1000: fix Rx and Tx queue state > > net/ena: fix Rx and Tx queue state > > net/enetc: fix Rx and Tx queue state > > net/enic: fix Rx and Tx queue state > > net/hinic: fix Rx and Tx queue state > > net/ipn3ke: fix Rx and Tx queue state > > net/memif: fix Rx and Tx queue state > > net/mana: fix Rx and Tx queue state > > net/mlx4: fix Rx and Tx queue state > > net/mvneta: fix Rx and Tx queue state > > net/mvpp2: fix Rx and Tx queue state > > net/netvsc: fix Rx and Tx queue state > > net/nfp: fix Rx and Tx queue state > > net/ngbe: fix Rx and Tx queue state > > net/null: fix Rx and Tx queue state > > net/octeon_ep: fix Rx and Tx queue state > > net/octeontx: fix Rx and Tx queue state > > net/pfe: fix Rx and Tx queue state > > net/ring: fix Rx and Tx queue state > > net/sfc: fix Rx and Tx queue state > > net/softnic: fix Rx and Tx queue state > > net/txgbe: fix Rx and Tx queue state > > net/vhost: fix Rx and Tx queue state > > net/virtio: fix Rx and Tx queue state > > net/vmxnet3: fix Rx and Tx queue state > > app/testpmd: fix primary process not polling all queues > > > > For series, > Acked-by: Ferruh Yigit <ferruh.yigit@amd.com> I see this series as a failure in having common code in ethdev. I hope we can revert it later to have a better ethdev code which update queue states taking deferred start into account. It may require to rework all drivers to have a common behaviour, but it would be a better improvement.