All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	Lijun Ou <oulijun@huawei.com>,
	"thomas@monjalon.net" <thomas@monjalon.net>,
	Ori Kam <orika@nvidia.com>,
	Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"linuxarm@openeuler.org" <linuxarm@openeuler.org>
Subject: Re: [dpdk-dev] [PATCH V2] ethdev: add queue state when retrieve queue information
Date: Wed, 14 Apr 2021 11:40:16 +0100	[thread overview]
Message-ID: <c550964c-2966-8856-7e08-3817412c2091@intel.com> (raw)
In-Reply-To: <DM6PR11MB44910BE8EF0AFE44356C4D2D9A769@DM6PR11MB4491.namprd11.prod.outlook.com>

Hi Lijun,

Let's try to complete this for the release.

On 4/6/2021 3:02 PM, Ananyev, Konstantin wrote:
> Hi,
> 
>> Currently, upper-layer application could get queue state only
>> through pointers such as dev->data->tx_queue_state[queue_id],
>> this is not the recommended way to access it. So this patch
>> add get queue state when call rte_eth_rx_queue_info_get and
>> rte_eth_tx_queue_info_get API.
>>
>> Note: The hairpin queue is not supported with above
>> rte_eth_*x_queue_info_get, so the queue state could be
>> RTE_ETH_QUEUE_STATE_STARTED or RTE_ETH_QUEUE_STATE_STOPPED.
> 
> I wonder why RTE_ETH_QUEUE_STATE_HAIRPIN Is not supported?
> Obviously what we do - copy internal queue state to the user provided buffer.
> 

+1, with current implementation we can't say it is only for start & stop.

Since 'STATE_HAIRPIN' is all internal, it may be possible to separate it into 
its own variable and expose only start and stop, but I don't think it worth the 
effort, why not just expose all possible states.


>> Note: After add queue_state field, the 'struct rte_eth_rxq_info' size
>> remains 128B, and the 'struct rte_eth_txq_info' size remains 64B, so
>> it could be ABI compatible.
>>
>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
>> Signed-off-by: Lijun Ou <oulijun@huawei.com>
>> ---
>> V1->V2:
>> - move queue state defines to public file
>> ---
>>   doc/guides/rel_notes/release_21_05.rst |  6 ++++++
>>   lib/librte_ethdev/ethdev_driver.h      |  7 -------
>>   lib/librte_ethdev/rte_ethdev.c         |  3 +++
>>   lib/librte_ethdev/rte_ethdev.h         | 11 +++++++++++
>>   4 files changed, 20 insertions(+), 7 deletions(-)
>>
>> diff --git a/doc/guides/rel_notes/release_21_05.rst b/doc/guides/rel_notes/release_21_05.rst
>> index 22aa80a..503daf9 100644
>> --- a/doc/guides/rel_notes/release_21_05.rst
>> +++ b/doc/guides/rel_notes/release_21_05.rst
>> @@ -164,6 +164,12 @@ ABI Changes
>>
>>   * No ABI change that would break compatibility with 20.11.
>>
>> +* Added new field ``queue_state`` to ``rte_eth_rxq_info`` structure
>> +  to provide indicated rxq queue state.
>> +
>> +* Added new field ``queue_state`` to ``rte_eth_txq_info`` structure
>> +  to provide indicated txq queue state.
>> +
>>
>>   Known Issues
>>   ------------
>> diff --git a/lib/librte_ethdev/ethdev_driver.h b/lib/librte_ethdev/ethdev_driver.h
>> index cdd4b43..ec5a17d 100644
>> --- a/lib/librte_ethdev/ethdev_driver.h
>> +++ b/lib/librte_ethdev/ethdev_driver.h
>> @@ -970,13 +970,6 @@ struct eth_dev_ops {
>>   };
>>
>>   /**
>> - * RX/TX queue states
>> - */
>> -#define RTE_ETH_QUEUE_STATE_STOPPED 0
>> -#define RTE_ETH_QUEUE_STATE_STARTED 1
>> -#define RTE_ETH_QUEUE_STATE_HAIRPIN 2
>> -
>> -/**
>>    * @internal
>>    * Check if the selected Rx queue is hairpin queue.
>>    *
>> diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
>> index 3059aa5..fbd10b2 100644
>> --- a/lib/librte_ethdev/rte_ethdev.c
>> +++ b/lib/librte_ethdev/rte_ethdev.c
>> @@ -5042,6 +5042,8 @@ rte_eth_rx_queue_info_get(uint16_t port_id, uint16_t queue_id,
>>
>>   memset(qinfo, 0, sizeof(*qinfo));
>>   dev->dev_ops->rxq_info_get(dev, queue_id, qinfo);
>> +qinfo->queue_state = dev->data->rx_queue_state[queue_id];
>> +
>>   return 0;
>>   }
>>
>> @@ -5082,6 +5084,7 @@ rte_eth_tx_queue_info_get(uint16_t port_id, uint16_t queue_id,
>>
>>   memset(qinfo, 0, sizeof(*qinfo));
>>   dev->dev_ops->txq_info_get(dev, queue_id, qinfo);
>> +qinfo->queue_state = dev->data->tx_queue_state[queue_id];
>>
>>   return 0;
>>   }
>> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
>> index efda313..4f0b1b2 100644
>> --- a/lib/librte_ethdev/rte_ethdev.h
>> +++ b/lib/librte_ethdev/rte_ethdev.h
>> @@ -1582,6 +1582,13 @@ struct rte_eth_dev_info {
>>   };
>>
>>   /**
>> + * RX/TX queue states
>> + */
>> +#define RTE_ETH_QUEUE_STATE_STOPPED 0
>> +#define RTE_ETH_QUEUE_STATE_STARTED 1
>> +#define RTE_ETH_QUEUE_STATE_HAIRPIN 2
>> +
>> +/**
>>    * Ethernet device RX queue information structure.
>>    * Used to retrieve information about configured queue.
>>    */
>> @@ -1591,6 +1598,8 @@ struct rte_eth_rxq_info {
>>   uint8_t scattered_rx;       /**< scattered packets RX supported. */
>>   uint16_t nb_desc;           /**< configured number of RXDs. */
>>   uint16_t rx_buf_size;       /**< hardware receive buffer size. */
>> +/**< Queues state: STARTED(1) / STOPPED(0). */
> 
> I think comment has to state that possible values are one of
> RTE_ETH_QUEUE_STATE_*.
> About previous discussion about new field in this struct vs new API function,
> I still think new function will be a bit cleaner, but could live with both.
> 
>> +uint8_t queue_state;
> 
> If we'll go with new 1B field, then as Stephen pointed,
> it is probably worth to fill the hole between scattered_rx
> and nb_desc with this new filed.
> 

+1

>>   } __rte_cache_min_aligned;
>>
>>   /**
>> @@ -1600,6 +1609,8 @@ struct rte_eth_rxq_info {
>>   struct rte_eth_txq_info {
>>   struct rte_eth_txconf conf; /**< queue config parameters. */
>>   uint16_t nb_desc;           /**< configured number of TXDs. */
>> +/**< Queues state: STARTED(1) / STOPPED(0). */
> 
> Same about comment here.
> 
>> +uint8_t queue_state;
>>   } __rte_cache_min_aligned;
>>
>>   /* Generic Burst mode flag definition, values can be ORed. */
>> --
>> 2.7.4
> 


Other comments I case see:

1- Make QUEUE_STATE enum
   For consistency with existing usage I think we can keep it as it is

2- Make a specific API to get the queue state
   No strong opinion, I think we can go with this one

3- Use enum type in "struct rte_eth_rxq_info"
   Which make sense but we don't have space in current struct, also 
'rte_eth_dev_data' has variable to hold same, and for consistency if we change 
it to enum in it, that is even wider change. I think it doesn't worth the effort 
and we can continue with 'uint8_t'

Please add if any is missing, and if there is any strong opinion on above.


If there is no objection, only required changes are above two issues commented 
inline,
- Remove comment/note that this is only for start/stop states
- Replace the field location to benefit from gap in struct

  reply	other threads:[~2021-04-14 10:40 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-18 12:25 [dpdk-dev] [PATCH] ethdev: add queue state when retrieve queue information Lijun Ou
2021-03-22  9:22 ` Ferruh Yigit
2021-03-22  9:38   ` Kinsella, Ray
2021-03-22  9:39   ` oulijun
2021-03-22 14:49   ` Andrew Rybchenko
2021-03-22 15:45     ` Ananyev, Konstantin
2021-03-22 16:02       ` Andrew Rybchenko
2021-03-22 16:53         ` Ananyev, Konstantin
2021-03-22 17:07           ` Andrew Rybchenko
2021-03-22 18:53             ` Ananyev, Konstantin
2021-03-23 10:13               ` Ferruh Yigit
2021-03-23 10:19                 ` Ferruh Yigit
2021-03-23 11:07                 ` Ananyev, Konstantin
2021-03-25 10:01       ` oulijun
2021-03-25 10:18         ` Ananyev, Konstantin
2021-03-25 11:09 ` [dpdk-dev] [PATCH V2] " Lijun Ou
2021-04-06  0:49   ` oulijun
2021-04-06  1:55     ` Stephen Hemminger
2021-04-14 10:09       ` Ferruh Yigit
2021-04-06 14:02   ` Ananyev, Konstantin
2021-04-14 10:40     ` Ferruh Yigit [this message]
2021-04-14 10:56       ` Ananyev, Konstantin
2021-04-15  2:40   ` [dpdk-dev] [PATCH V3] " Lijun Ou
2021-04-15 12:33     ` Ferruh Yigit
2021-04-15 12:36       ` Thomas Monjalon
2021-04-15 12:45         ` Ferruh Yigit
2021-04-15 13:34           ` Thomas Monjalon
2021-04-16  0:58           ` [dpdk-dev] [Linuxarm] " oulijun
2021-04-16  7:31             ` Ferruh Yigit
2021-04-16  8:46     ` [dpdk-dev] [PATCH V4] " Lijun Ou
2021-04-16  8:58       ` Thomas Monjalon
2021-04-16  9:41         ` Ferruh Yigit
2021-04-16  9:57           ` Thomas Monjalon
2021-04-23 11:08             ` Kinsella, Ray
2021-04-25 16:42               ` Thomas Monjalon
2021-04-26  9:48                 ` Kinsella, Ray
2021-04-16  9:55         ` oulijun
2021-04-16  9:19       ` Ananyev, Konstantin
2021-04-17  3:09       ` [dpdk-dev] [PATCH V5] " Lijun Ou
2021-04-17 22:00         ` Ferruh Yigit
2021-04-19  1:39           ` oulijun
2021-04-19  2:04           ` oulijun
2021-04-19  2:03         ` [dpdk-dev] [PATCH V6] " Lijun Ou
2021-04-19  8:41           ` Thomas Monjalon
2021-04-19  8:58             ` oulijun
2021-04-19  8:57           ` [dpdk-dev] [PATCH v7] " Lijun Ou
2021-04-19  9:03             ` Thomas Monjalon
2021-04-19 10:48               ` Ferruh Yigit
2021-04-23 11:17         ` [dpdk-dev] [PATCH V5] " Kinsella, Ray
2021-04-23 11:26           ` Ananyev, Konstantin
2021-04-23 15:43             ` Kinsella, Ray

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c550964c-2966-8856-7e08-3817412c2091@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=konstantin.ananyev@intel.com \
    --cc=linuxarm@openeuler.org \
    --cc=orika@nvidia.com \
    --cc=oulijun@huawei.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.