DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>,
	Lijun Ou <oulijun@huawei.com>,
	"thomas@monjalon.net" <thomas@monjalon.net>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"linuxarm@openeuler.org" <linuxarm@openeuler.org>,
	Andrew Rybchenko <arybchenko@solarflare.com>,
	"David Marchand" <david.marchand@redhat.com>,
	Ray Kinsella <mdr@ashroe.eu>, "Luca Boccassi" <bluca@debian.org>
Subject: Re: [dpdk-dev] [PATCH] ethdev: add queue state when retrieve queue information
Date: Mon, 22 Mar 2021 18:53:04 +0000	[thread overview]
Message-ID: <DM6PR11MB44918E67DEA308881AC8C5909A659@DM6PR11MB4491.namprd11.prod.outlook.com> (raw)
In-Reply-To: <74bd828c-9f2c-17ff-9f8e-d06643db04e5@oktetlabs.ru>



> -----Original Message-----
> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> Sent: Monday, March 22, 2021 5:08 PM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; Yigit, Ferruh <ferruh.yigit@intel.com>; Lijun Ou <oulijun@huawei.com>;
> thomas@monjalon.net
> Cc: dev@dpdk.org; linuxarm@openeuler.org; Andrew Rybchenko <arybchenko@solarflare.com>; David Marchand
> <david.marchand@redhat.com>; Ray Kinsella <mdr@ashroe.eu>; Luca Boccassi <bluca@debian.org>
> Subject: Re: [dpdk-dev] [PATCH] ethdev: add queue state when retrieve queue information
> 
> On 3/22/21 7:53 PM, Ananyev, Konstantin wrote:
> >
> >
> >> -----Original Message-----
> >> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> >> Sent: Monday, March 22, 2021 4:02 PM
> >> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; Yigit, Ferruh <ferruh.yigit@intel.com>; Lijun Ou <oulijun@huawei.com>;
> >> thomas@monjalon.net
> >> Cc: dev@dpdk.org; linuxarm@openeuler.org; Andrew Rybchenko <arybchenko@solarflare.com>; David Marchand
> >> <david.marchand@redhat.com>; Ray Kinsella <mdr@ashroe.eu>; Luca Boccassi <bluca@debian.org>
> >> Subject: Re: [dpdk-dev] [PATCH] ethdev: add queue state when retrieve queue information
> >>
> >> On 3/22/21 6:45 PM, Ananyev, Konstantin wrote:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: dev <dev-bounces@dpdk.org> On Behalf Of Andrew Rybchenko
> >>>> Sent: Monday, March 22, 2021 2:49 PM
> >>>> To: Yigit, Ferruh <ferruh.yigit@intel.com>; Lijun Ou <oulijun@huawei.com>; thomas@monjalon.net
> >>>> Cc: dev@dpdk.org; linuxarm@openeuler.org; Andrew Rybchenko <arybchenko@solarflare.com>; David Marchand
> >>>> <david.marchand@redhat.com>; Ray Kinsella <mdr@ashroe.eu>; Luca Boccassi <bluca@debian.org>
> >>>> Subject: Re: [dpdk-dev] [PATCH] ethdev: add queue state when retrieve queue information
> >>>>
> >>>> On 3/22/21 12:22 PM, Ferruh Yigit wrote:
> >>>>> On 3/18/2021 12:25 PM, Lijun Ou wrote:
> >>>>>> 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.
> >>>>>> 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>
> >>>>>
> >>>>> <...>
> >>>>>
> >>>>>> diff --git a/lib/librte_ethdev/rte_ethdev.h
> >>>>>> b/lib/librte_ethdev/rte_ethdev.h
> >>>>>> index efda313..3b83c5a 100644
> >>>>>> --- a/lib/librte_ethdev/rte_ethdev.h
> >>>>>> +++ b/lib/librte_ethdev/rte_ethdev.h
> >>>>>> @@ -1591,6 +1591,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). */
> >>>>>> +    uint8_t queue_state;
> >>>>>>   } __rte_cache_min_aligned;
> >>>>>>     /**
> >>>>>> @@ -1600,6 +1602,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). */
> >>>>>> +    uint8_t queue_state;
> >>>>>>   } __rte_cache_min_aligned;
> >>>>>>     /* Generic Burst mode flag definition, values can be ORed. */
> >>>>>>
> >>>>>
> >>>>> This is causing an ABI warning [1], but I guess it is safe since the
> >>>>> size of the struct is not changing (cache align). Adding a few more
> >>>>> people to comment.
> >>>>>
> >>>>>
> >>>>> [1]
> >>>>> https://travis-ci.com/github/ovsrobot/dpdk/builds/220497651
> >>>>
> >>>> Frankly speaking I dislike addition of queue_state as uint8_t.
> >>>> IMHO it should be either 'bool started' or enum to support more
> >>>> states in the future if we need.
> >>>
> >>> I think we already have set of defines for it:
> >>> lib/librte_ethdev/rte_ethdev_driver.h:925:#define RTE_ETH_QUEUE_STATE_STOPPED 0
> >>> lib/librte_ethdev/rte_ethdev_driver.h:926:#define RTE_ETH_QUEUE_STATE_STARTED 1
> >>> lib/librte_ethdev/rte_ethdev_driver.h:927:#define RTE_ETH_QUEUE_STATE_HAIRPIN 2
> >>>
> >>> If we want to publish it, then might be enough just move these macros to rte_ethdev.h or so.
> >>>
> >>> About uint8_t vs enum - yes, in principle enum would be a bit nicer,
> >>> but right now rte_eth_dev_data.(rx|tx)_queue_state[]  itself is an array of uint8_t.
> >>> So probably not much point to waste extra 3B in rte_eth_(rxq|txq)_info.
> >>> Unless in future will want to change it in struct rte_eth_dev_data too
> >>> (or even hide it inside dev private queue data).
> >>
> >> I forgot about hairpin and bitmask... If so, I think it is
> >> sufficient to fix absolutely misleading comment, say
> >> that it is a bit mask and think about removal of
> >> RTE_ETH_QUEUE_STATE_STOPPED (since it could be
> >> stopped+hairpin). May be consider to use uin16_t,
> >> since 8 bit is really small bitmask. It still fits in
> >> available hole.
> >
> > Hmm, as I can read the code - hairpin queue can't be started/stopped by SW,
> > and each of the states (stopped/started/hairpin) is mutually exclusive.
> > Is that not what was intended when hairpin queues were introduced?
> >
> 
> Thanks, yes, you're right. My memory lies to me. If queue state
> is not a bit mask, it should be an enum from API point of view.
> Rx/Tx queue info structures are control path. I see no point to
> save bits here. Clear API is more important on control path.
> The only reason here to use uint8_t is to avoid ABI breakage.
> I can't judge if it is critical to wait or not.

As alternate thought - introduce new API function,
something like:
int rte_eth_get_rxq_state(portid, queue_id);
Then rte_eth_dev_is_rx_hairpin_queue() probably can be deprecated
in favour of this new one.  



  reply	other threads:[~2021-03-22 18:53 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-18 12:25 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 [this message]
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
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=DM6PR11MB44918E67DEA308881AC8C5909A659@DM6PR11MB4491.namprd11.prod.outlook.com \
    --to=konstantin.ananyev@intel.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=arybchenko@solarflare.com \
    --cc=bluca@debian.org \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=linuxarm@openeuler.org \
    --cc=mdr@ashroe.eu \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).