[00/36] fix Rx and Tx queue state

  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(-)
  

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.