DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Jerin Jacob <jerinjacobk@gmail.com>
Cc: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	"Morten Brørup" <mb@smartsharesystems.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	"olivier.matz@6wind.com" <olivier.matz@6wind.com>,
	"andrew.rybchenko@oktetlabs.ru" <andrew.rybchenko@oktetlabs.ru>,
	"honnappa.nagarahalli@arm.com" <honnappa.nagarahalli@arm.com>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>,
	"jerinj@marvell.com" <jerinj@marvell.com>,
	"gakhil@marvell.com" <gakhil@marvell.com>
Subject: Re: [dpdk-dev] [PATCH] parray: introduce internal API for dynamic arrays
Date: Tue, 15 Jun 2021 11:18:11 +0200	[thread overview]
Message-ID: <1725976.ZNbi1HEfbS@thomas> (raw)
In-Reply-To: <CALBAE1OVu2xoXK7TsETVA+DoOFdmNCF+rRcOjQBfN-SdshrdZw@mail.gmail.com>

15/06/2021 10:00, Jerin Jacob:
> On Tue, Jun 15, 2021 at 12:22 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> > 14/06/2021 17:48, Jerin Jacob:
> > > On Mon, Jun 14, 2021 at 8:29 PM Ananyev, Konstantin
> > > <konstantin.ananyev@intel.com> wrote:
> > > > > 14/06/2021 15:15, Bruce Richardson:
> > > > > > While I dislike the hard-coded limits in DPDK, I'm also not convinced that
> > > > > > we should switch away from the flat arrays or that we need fully dynamic
> > > > > > arrays that grow/shrink at runtime for ethdevs. I would suggest a half-way
> > > > > > house here, where we keep the ethdevs as an array, but one allocated/sized
> > > > > > at runtime rather than statically. This would allow us to have a
> > > > > > compile-time default value, but, for use cases that need it, allow use of a
> > > > > > flag e.g.  "max-ethdevs" to change the size of the parameter given to the
> > > > > > malloc call for the array.  This max limit could then be provided to apps
> > > > > > too if they want to match any array sizes. [Alternatively those apps could
> > > > > > check the provided size and error out if the size has been increased beyond
> > > > > > what the app is designed to use?]. There would be no extra dereferences per
> > > > > > rx/tx burst call in this scenario so performance should be the same as
> > > > > > before (potentially better if array is in hugepage memory, I suppose).
> > > > >
> > > > > I think we need some benchmarks to decide what is the best tradeoff.
> > > > > I spent time on this implementation, but sorry I won't have time for benchmarks.
> > > > > Volunteers?
> > > >
> > > > I had only a quick look at your approach so far.
> > > > But from what I can read, in MT environment your suggestion will require
> > > > extra synchronization for each read-write access to such parray element (lock, rcu, ...).
> > > > I think what Bruce suggests will be much ligther, easier to implement and less error prone.
> > > > At least for rte_ethdevs[] and friends.
> > >
> > > +1
> >
> > Please could you have a deeper look and tell me why we need more locks?
> 
> We don't need more locks (It is fat mutex) now in the implementation.
> 
> If it needs to use in fastpath, we need more state of art
> synchronization like RCU.
> 
> Also, you can take look at VPP dynamic array implementation which is
> used in fastpath.
> 
> https://docs.fd.io/vpp/21.10/db/d65/vec_8h.html
> 
> So the question is the use case for this API. Is it for slowpath item
> like ethdev[] memory
> or fastpath items like holding an array of mbuf etc.

As I replied to Morten, it is for read in fast path
and alloc/free in slow path.
I should highlight this in the commit log if there is a v2.
That's why there is a mutex in alloc/free and nothing in read access.

> > The element pointers doesn't change.
> > Only the array pointer change at resize,
> > but the old one is still usable until the next resize.
> > I think we don't need more.




  reply	other threads:[~2021-06-15  9:18 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-14 10:58 Thomas Monjalon
2021-06-14 12:22 ` Morten Brørup
2021-06-14 13:15   ` Bruce Richardson
2021-06-14 13:32     ` Thomas Monjalon
2021-06-14 14:59       ` Ananyev, Konstantin
2021-06-14 15:48         ` Jerin Jacob
2021-06-15  6:52           ` Thomas Monjalon
2021-06-15  8:00             ` Jerin Jacob
2021-06-15  9:18               ` Thomas Monjalon [this message]
2021-06-15  9:33             ` Ananyev, Konstantin
2021-06-15  9:50               ` Thomas Monjalon
2021-06-15 10:08                 ` Ananyev, Konstantin
2021-06-15 14:02                   ` Thomas Monjalon
2021-06-15 14:37                     ` Honnappa Nagarahalli
2021-06-14 15:54         ` Ananyev, Konstantin
2021-06-17 13:08           ` Ferruh Yigit
2021-06-17 14:58             ` Ananyev, Konstantin
2021-06-17 15:17               ` Morten Brørup
2021-06-17 16:12                 ` Ferruh Yigit
2021-06-17 16:55                   ` Morten Brørup
2021-06-18 10:21                     ` Ferruh Yigit
2021-06-17 17:05                   ` Ananyev, Konstantin
2021-06-18  9:14                     ` Morten Brørup
2021-06-18 10:47                       ` Ferruh Yigit
2021-06-18 11:16                         ` Morten Brørup
2021-06-18 10:28                     ` Ferruh Yigit
2021-06-17 15:44               ` Ferruh Yigit
2021-06-18 10:41                 ` Ananyev, Konstantin
2021-06-18 10:49                   ` Ferruh Yigit
2021-06-21 11:06                   ` Ananyev, Konstantin
2021-06-21 12:10                     ` Morten Brørup
2021-06-21 12:30                       ` Ananyev, Konstantin
2021-06-21 13:28                         ` Morten Brørup
     [not found]                           ` <DM6PR11MB4491D4F6FAFDD6E8EEC2A78F9A099@DM6PR11MB4491.namprd11.prod.outlook .com>
2021-06-22  8:33                           ` Ananyev, Konstantin
2021-06-22 10:01                             ` Morten Brørup
2021-06-22 12:13                               ` Ananyev, Konstantin
2021-06-22 13:18                                 ` Morten Brørup
2021-06-21 14:10                         ` Ferruh Yigit
2021-06-21 14:38                           ` Ananyev, Konstantin
2021-06-21 15:56                             ` Ferruh Yigit
2021-06-21 18:17                               ` Ananyev, Konstantin
2021-06-21 14:05                     ` Ferruh Yigit
2021-06-21 14:42                       ` Ananyev, Konstantin
2021-06-21 15:32                         ` Ferruh Yigit
2021-06-21 15:37                           ` Ananyev, Konstantin
2021-06-14 15:48       ` Morten Brørup
2021-06-15  6:48         ` Thomas Monjalon
2021-06-15  7:53           ` Morten Brørup
2021-06-15  8:44             ` Bruce Richardson
2021-06-15  9:28               ` Thomas Monjalon
2021-06-16  9:42           ` Jerin Jacob
2021-06-16 11:27             ` Morten Brørup
2021-06-16 12:00               ` Jerin Jacob
2021-06-16 13:02               ` Bruce Richardson
2021-06-16 15:01                 ` Morten Brørup
2021-06-16 17:40                   ` Bruce Richardson
2021-06-16 12:22             ` Burakov, Anatoly
2021-06-16 12:59               ` Jerin Jacob
2021-06-16 22:58                 ` Dmitry Kozlyuk
2021-06-14 13:28   ` Thomas Monjalon
2021-06-16 11:11 ` Burakov, Anatoly

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=1725976.ZNbi1HEfbS@thomas \
    --to=thomas@monjalon.net \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=gakhil@marvell.com \
    --cc=honnappa.nagarahalli@arm.com \
    --cc=jerinj@marvell.com \
    --cc=jerinjacobk@gmail.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=mb@smartsharesystems.com \
    --cc=olivier.matz@6wind.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).