DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: "Morten Brørup" <mb@smartsharesystems.com>
Cc: dev@dpdk.org, nd@arm.com, Honnappa.Nagarahalli@arm.com,
	Feifei Wang <feifei.wang2@arm.com>,
	Ruifeng Wang <ruifeng.wang@arm.com>,
	Feifei Wang <feifei.wang2@arm.com>,
	ferruh.yigit@amd.com, konstantin.ananyev@huawei.com,
	andrew.rybchenko@oktetlabs.ru
Subject: Re: [PATCH] doc: announce ethdev operation struct changes
Date: Fri, 28 Jul 2023 17:37:30 +0200	[thread overview]
Message-ID: <3047655.CbtlEUcBR6@thomas> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D87AA4@smartserver.smartshare.dk>

28/07/2023 17:33, Morten Brørup:
> > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > Sent: Friday, 28 July 2023 17.20
> > 
> > 28/07/2023 17:08, Morten Brørup:
> > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > Sent: Friday, 28 July 2023 16.57
> > > >
> > > > 04/07/2023 10:10, Feifei Wang:
> > > > > To support mbufs recycle mode, announce the coming ABI changes
> > > > > from DPDK 23.11.
> > > > >
> > > > > Signed-off-by: Feifei Wang <feifei.wang2@arm.com>
> > > > > Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
> > > > > ---
> > > > >  doc/guides/rel_notes/deprecation.rst | 4 ++++
> > > > >  1 file changed, 4 insertions(+)
> > > > >
> > > > > diff --git a/doc/guides/rel_notes/deprecation.rst
> > > > b/doc/guides/rel_notes/deprecation.rst
> > > > > index 66431789b0..c7e1ffafb2 100644
> > > > > --- a/doc/guides/rel_notes/deprecation.rst
> > > > > +++ b/doc/guides/rel_notes/deprecation.rst
> > > > > @@ -118,6 +118,10 @@ Deprecation Notices
> > > > >    The legacy actions should be removed
> > > > >    once ``MODIFY_FIELD`` alternative is implemented in drivers.
> > > > >
> > > > > +* ethdev: The Ethernet device data structure ``struct rte_eth_dev`` and
> > > > > +  the fast-path ethdev flat array ``struct rte_eth_fp_ops`` will be
> > updated
> > > > > +  with new fields to support mbufs recycle mode from DPDK 23.11.
> > >
> > > Existing fields will also be moved around [1]:
> > >
> > > @@ -83,15 +90,17 @@  struct rte_eth_fp_ops {
> > >  	 * Rx fast-path functions and related data.
> > >  	 * 64-bit systems: occupies first 64B line
> > >  	 */
> > > +	/** Rx queues data. */
> > > +	struct rte_ethdev_qdata rxq;
> > >  	/** PMD receive function. */
> > >  	eth_rx_burst_t rx_pkt_burst;
> > >  	/** Get the number of used Rx descriptors. */
> > >  	eth_rx_queue_count_t rx_queue_count;
> > >  	/** Check the status of a Rx descriptor. */
> > >  	eth_rx_descriptor_status_t rx_descriptor_status;
> > > -	/** Rx queues data. */
> > > -	struct rte_ethdev_qdata rxq;
> > > -	uintptr_t reserved1[3];
> > > +	/** Refill Rx descriptors with the recycling mbufs. */
> > > +	eth_recycle_rx_descriptors_refill_t recycle_rx_descriptors_refill;
> > > +	uintptr_t reserved1[2];
> > >  	/**@}*/
> > >
> > >  	/**@{*/
> > > @@ -99,15 +108,17 @@  struct rte_eth_fp_ops {
> > >  	 * Tx fast-path functions and related data.
> > >  	 * 64-bit systems: occupies second 64B line
> > >  	 */
> > > +	/** Tx queues data. */
> > > +	struct rte_ethdev_qdata txq;
> > >  	/** PMD transmit function. */
> > >  	eth_tx_burst_t tx_pkt_burst;
> > >  	/** PMD transmit prepare function. */
> > >  	eth_tx_prep_t tx_pkt_prepare;
> > >  	/** Check the status of a Tx descriptor. */
> > >  	eth_tx_descriptor_status_t tx_descriptor_status;
> > > -	/** Tx queues data. */
> > > -	struct rte_ethdev_qdata txq;
> > > -	uintptr_t reserved2[3];
> > > +	/** Copy used mbufs from Tx mbuf ring into Rx. */
> > > +	eth_recycle_tx_mbufs_reuse_t recycle_tx_mbufs_reuse;
> > > +	uintptr_t reserved2[2];
> > >  	/**@}*/
> > 
> > Removing existing fields should be announced explicitly.
> 
> Agreed. And the patch misses this. The "rxq" and "txq" fields are not being removed, they are being moved up in the structures. Your comment about explicit mentioning still applies!
> 
> If there's no time to wait for a new patch version from Feifei, perhaps you improve the description while merging.

If it's only moving fields, we can skip.
The real change is the size of the reserved fields,
so it looks acceptable without notice.



  reply	other threads:[~2023-07-28 15:37 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-04  8:10 Feifei Wang
2023-07-04  8:17 ` Feifei Wang
2023-07-13  2:37   ` Feifei Wang
2023-07-13 12:50     ` Morten Brørup
2023-07-17  8:28       ` Andrew Rybchenko
2023-07-05 11:32 ` Konstantin Ananyev
2023-07-13  7:52   ` Ferruh Yigit
2023-07-28 14:56 ` Thomas Monjalon
2023-07-28 15:04   ` Thomas Monjalon
2023-07-28 15:08   ` Morten Brørup
2023-07-28 15:20     ` Thomas Monjalon
2023-07-28 15:33       ` Morten Brørup
2023-07-28 15:37         ` Thomas Monjalon [this message]
2023-07-28 15:55           ` Morten Brørup
2023-08-01  3:19             ` Feifei Wang

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=3047655.CbtlEUcBR6@thomas \
    --to=thomas@monjalon.net \
    --cc=Honnappa.Nagarahalli@arm.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=feifei.wang2@arm.com \
    --cc=ferruh.yigit@amd.com \
    --cc=konstantin.ananyev@huawei.com \
    --cc=mb@smartsharesystems.com \
    --cc=nd@arm.com \
    --cc=ruifeng.wang@arm.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).