DPDK patches and discussions
 help / color / mirror / Atom feed
From: Konstantin Ananyev <konstantin.ananyev@huawei.com>
To: "Morten Brørup" <mb@smartsharesystems.com>,
	"Stephen Hemminger" <stephen@networkplumber.org>,
	"skori@marvell.com" <skori@marvell.com>
Cc: Shepard Siegel <shepard.siegel@atomicrules.com>,
	Ed Czeck <ed.czeck@atomicrules.com>,
	John Miller <john.miller@atomicrules.com>,
	"Igor Russkikh" <irusskikh@marvell.com>,
	Ajit Khaparde <ajit.khaparde@broadcom.com>,
	Somnath Kotur <somnath.kotur@broadcom.com>,
	Nithin Dabilpuram <ndabilpuram@marvell.com>,
	Kiran Kumar K <kirankumark@marvell.com>,
	Satha Rao <skoteshwar@marvell.com>,
	Harman Kalra <hkalra@marvell.com>,
	Hemant Agrawal <hemant.agrawal@nxp.com>,
	Sachin Saxena <sachin.saxena@nxp.com>,
	John Daley <johndale@cisco.com>,
	Hyong Youb Kim <hyonkim@cisco.com>,
	Ian Stokes <ian.stokes@intel.com>,
	Bruce Richardson <bruce.richardson@intel.com>,
	Vladimir Medvedkin <vladimir.medvedkin@intel.com>,
	Anatoly Burakov <anatoly.burakov@intel.com>,
	Dariusz Sosnowski <dsosnowski@nvidia.com>,
	Viacheslav Ovsiienko <viacheslavo@nvidia.com>,
	Bing Zhao <bingz@nvidia.com>, Ori Kam <orika@nvidia.com>,
	Suanming Mou <suanmingm@nvidia.com>,
	Matan Azrad <matan@nvidia.com>, Long Li <longli@microsoft.com>,
	Wei Hu <weh@microsoft.com>,
	Chaoyong He <chaoyong.he@corigine.com>,
	Jiawen Wu <jiawenwu@trustnetic.com>,
	Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
	Jerin Jacob <jerinj@marvell.com>,
	Maciej Czekaj <mczekaj@marvell.com>,
	"Jian Wang" <jianwang@trustnetic.com>,
	Maxime Coquelin <maxime.coquelin@redhat.com>,
	Chenbo Xia <chenbox@nvidia.com>,
	Jochen Behrens <jochen.behrens@broadcom.com>,
	Thomas Monjalon <thomas@monjalon.net>,
	"Ferruh Yigit" <ferruh.yigit@amd.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: RE: [PATCH v2 1/2] ethdev: remove unnecessary type conversion
Date: Wed, 28 May 2025 09:14:27 +0000	[thread overview]
Message-ID: <581e7a5389f842a9824a365a46c470ad@huawei.com> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9FC9D@smartserver.smartshare.dk>



> 
> > From: Konstantin Ananyev [mailto:konstantin.ananyev@huawei.com]
> > Sent: Wednesday, 28 May 2025 10.24
> >
> > > >
> > > > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > > > Sent: Tuesday, 27 May 2025 17.07
> > > > >
> > > > > On Mon, 12 May 2025 20:37:19 +0530
> > > > > <skori@marvell.com> wrote:
> > > > >
> > > > > >  /**@{@name Rx hardware descriptor states
> > > > > > diff --git a/lib/ethdev/rte_ethdev_core.h
> > > > > b/lib/ethdev/rte_ethdev_core.h
> > > > > > index e55fb42996..4ffae4921a 100644
> > > > > > --- a/lib/ethdev/rte_ethdev_core.h
> > > > > > +++ b/lib/ethdev/rte_ethdev_core.h
> > > > > > @@ -45,7 +45,7 @@ typedef uint16_t (*eth_tx_prep_t)(void *txq,
> > > > > >
> > > > > >
> > > > > >  /** @internal Get number of used descriptors on a receive
> > queue. */
> > > > > > -typedef uint32_t (*eth_rx_queue_count_t)(void *rxq);
> > > > > > +typedef int (*eth_rx_queue_count_t)(void *rxq);
> > > > > >
> > > > > >  /** @internal Check the status of a Rx descriptor */
> > > > > >  typedef int (*eth_rx_descriptor_status_t)(void *rxq, uint16_t
> > > > > offset);
> > > > >
> > > > >
> > > > > This gets reported as ABI breakage. The change will have to wait
> > until
> > > > > next LTS (25.11)
> > > >
> > > > The return type was weird (wrong) to begin with.
> > > > When used, it gets cast to int:
> > > >
> > https://elixir.bootlin.com/dpdk/v25.03/source/lib/ethdev/rte_ethdev.h#L
> > 6404
> > >
> > > Personally, I don't see anything strange here.
> > > devops rx_queue_count() supposed to return uint, because it should
> > never failed for
> > > valid queue.
> 
> The main thing wrong is inconsistency with its sibling API for TX queue count:
> /** @internal Get number of used descriptors on a receive queue. */
> typedef uint32_t (*eth_rx_queue_count_t)(void *rxq);
> /** @internal Get number of used descriptors on a transmit queue. */
> typedef int (*eth_tx_queue_count_t)(void *txq);
> 
> > > While rte_eth_rx_queue_count() itself can fail - wrong port/queue id,
> > etc.
> >
> > BTW, rx_queue_setup() accepts only uint16_t for number of rx
> > descritoirs:
> > int rte_eth_rx_queue_setup(uint16_t port_id, uint16_t rx_queue_id,
> >                 uint16_t nb_rx_desc, unsigned int socket_id,
> >                 const struct rte_eth_rxconf *rx_conf,
> >                 struct rte_mempool *mb_pool);
> >
> > shouldn't dev->rx_queue_count() then also return uitn16_t (for
> > consistency)?
> 
> If neither the RX or TX queue count callbacks can fail, then yes, both APIs could be updated to return uint16_t.
> But it would be more future proof to allow these callbacks to fail, even on a valid queue.
> The public APIs rte_eth_rx/tx_queue_count() can fail, so passing on failures from the callbacks would not be a change of the public
> API. (Assuming no new error codes are allowed.)
> 
> And the "future" already arrived:
> The return type must be int (or have the same size as int), for the performance patch [1] replacing the ops->callback==NULL check
> with dummy callbacks returning -ENOTSUP.
> 
> [1]: https://inbox.dpdk.org/dev/20250512150732.65743-2-skori@marvell.com/

So what we are saving with that patch: one cmp and one un-taken branch:
@@ -6399,8 +6399,6 @@ rte_eth_rx_queue_count(uint16_t port_id, uint16_t queue_id)
 		return -EINVAL;
 #endif
 
-	if (p->rx_queue_count == NULL)
-		return -ENOTSUP;
 	return p->rx_queue_count(qd);
 }

I wonder is how realistic (and measurable) is the gain?

>   
> >
> > > >
> > > > You are right that it formally changes the ABI, and we should go
> > through the LTS motions.
> > > > But, for this change, I'd favor an exception.
> > >
> > > Again, from my opinion, there is nothing that urgent/important why
> > such changes (if needed)
> > > can't wait till next LTS.
> > > For now, we can simply do type conversion explicitly at
> > rte_eth_rx_queue_count().
> 
> OK. No objections from me. Just trying to accelerate some cleanup work.
> 
> > >
> > > > PS: As a consequence of this change, a patch to update the return
> > type of the callback in all the ethdev drivers should be provided.
> > > >
> > > > >
> > > > >
> > > > >   [C] 'rte_eth_fp_ops rte_eth_fp_ops[32]' was changed at
> > > > > rte_ethdev.c:47:1:
> > > > >     type of variable changed:
> > > > >       array element type 'struct rte_eth_fp_ops' changed:
> > > > >         type size hasn't changed
> > > > >         1 data member change:
> > > > >           type of 'eth_rx_queue_count_t rx_queue_count' changed:
> > > > >             underlying type 'uint32_t (*)(void*)' changed:
> > > > >               in pointed to type 'function type uint32_t
> > (void*)':
> > > > >                 return type changed:
> > > > >                   entity changed from 'typedef uint32_t' to 'int'
> > > > >                   type size hasn't changed
> > > > >       type size hasn't changed


  reply	other threads:[~2025-05-28  9:14 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-29 18:11 [PATCH] ethdev: remove callback checks from fast path skori
2025-04-29 23:55 ` Stephen Hemminger
2025-04-29 23:59 ` Stephen Hemminger
2025-04-30  7:26 ` Morten Brørup
2025-05-12 15:07 ` [PATCH v2 1/2] ethdev: remove unnecessary type conversion skori
2025-05-12 15:07   ` [PATCH v2 2/2] ethdev: remove callback checks from fast path skori
2025-05-12 16:12     ` Morten Brørup
2025-05-28  9:35     ` Morten Brørup
2025-05-12 16:04   ` [PATCH v2 1/2] ethdev: remove unnecessary type conversion Morten Brørup
2025-05-27 15:07   ` Stephen Hemminger
2025-05-27 16:24     ` Morten Brørup
2025-05-28  8:17       ` Konstantin Ananyev
2025-05-28  8:23         ` Konstantin Ananyev
2025-05-28  8:48           ` Morten Brørup
2025-05-28  9:14             ` Konstantin Ananyev [this message]
2025-05-28  9:39               ` Morten Brørup
2025-05-26 12:30 ` [EXTERNAL] [PATCH] ethdev: remove callback checks from fast path Jerin Jacob

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=581e7a5389f842a9824a365a46c470ad@huawei.com \
    --to=konstantin.ananyev@huawei.com \
    --cc=ajit.khaparde@broadcom.com \
    --cc=anatoly.burakov@intel.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=bingz@nvidia.com \
    --cc=bruce.richardson@intel.com \
    --cc=chaoyong.he@corigine.com \
    --cc=chenbox@nvidia.com \
    --cc=dev@dpdk.org \
    --cc=dsosnowski@nvidia.com \
    --cc=ed.czeck@atomicrules.com \
    --cc=ferruh.yigit@amd.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=hkalra@marvell.com \
    --cc=hyonkim@cisco.com \
    --cc=ian.stokes@intel.com \
    --cc=irusskikh@marvell.com \
    --cc=jerinj@marvell.com \
    --cc=jianwang@trustnetic.com \
    --cc=jiawenwu@trustnetic.com \
    --cc=jochen.behrens@broadcom.com \
    --cc=john.miller@atomicrules.com \
    --cc=johndale@cisco.com \
    --cc=kirankumark@marvell.com \
    --cc=longli@microsoft.com \
    --cc=matan@nvidia.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=mb@smartsharesystems.com \
    --cc=mczekaj@marvell.com \
    --cc=ndabilpuram@marvell.com \
    --cc=orika@nvidia.com \
    --cc=sachin.saxena@nxp.com \
    --cc=shepard.siegel@atomicrules.com \
    --cc=skori@marvell.com \
    --cc=skoteshwar@marvell.com \
    --cc=somnath.kotur@broadcom.com \
    --cc=stephen@networkplumber.org \
    --cc=suanmingm@nvidia.com \
    --cc=thomas@monjalon.net \
    --cc=viacheslavo@nvidia.com \
    --cc=vladimir.medvedkin@intel.com \
    --cc=weh@microsoft.com \
    /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).