DPDK patches and discussions
 help / color / mirror / Atom feed
From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
To: "Ruifeng Wang (Arm Technology China)" <Ruifeng.Wang@arm.com>,
	Stephen Hemminger <stephen@networkplumber.org>
Cc: "tomasz.kantecki@intel.com" <tomasz.kantecki@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	"Gavin Hu (Arm Technology China)" <Gavin.Hu@arm.com>,
	Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
	nd <nd@arm.com>, nd <nd@arm.com>
Subject: Re: [dpdk-dev] [PATCH 0/2] add lock-free mode for l3fwd
Date: Tue, 10 Sep 2019 16:27:50 +0000	[thread overview]
Message-ID: <VE1PR08MB5149CE35529A97B0FCE8ED3D98B60@VE1PR08MB5149.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <AM0PR08MB3986B48AFC3DBDBE08A7E3459EB70@AM0PR08MB3986.eurprd08.prod.outlook.com>

<snip>

> >
> > On Fri,  6 Sep 2019 18:26:13 +0800
> > Ruifeng Wang <ruifeng.wang@arm.com> wrote:
> >
> > > Lock-free mode is supported by hash library and LPM library.
> > > Now we add an option for l3fwd example to enable the lock-free mode.
> > > Necessary preparation steps are added to use lock-free LPM mode.
> >
> > If lock-free mode works it should just do that.
> > Having options mean that there are two test cases; which inevitably
> > leads to one of them being broken.
> 
> Agree that having options will add scenarios that being tested.
> Since these different scenarios are supported by Hash / LPM library, the tests
> on them should be valid.
> As l3fwd application is always used to benchmark data path performance,
> make both supported modes available can help user to easily collect data and
> compare.
> In the long run, we can make lock-free mode the default used by l3fwd when
> it is fine tuned.
I agree that if lock-free works we should just do that. It makes L3fwd application more practical.

The LPM has always been lock free on the data plane side. The writer side parts and quiescent state reporting on the data plane are being added now.

With the optimizations in the last release, the lock free hash algorithm's performance has come very close to RW lock based algorithm both for hit and miss cases for single core. Unfortunately (😊), any further optimizations seem to increase the performance of the RW lock based algorithm as well. So, looks like there will be that small difference between the 2 algorithms. However, a practical application will use other cores in the SoC and lock-free algorithms scale better with increasing number of cores. IMO, we should bite the bullet and make hash lock-free algorithm default.

      reply	other threads:[~2019-09-10 16:28 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-06 10:26 Ruifeng Wang
2019-09-06 10:26 ` [dpdk-dev] [PATCH 1/2] examples/l3fwd: add lock-free option " Ruifeng Wang
2019-09-06 10:26 ` [dpdk-dev] [PATCH 2/2] examples/l3fwd: integrate RCU QSBR for LPM mode Ruifeng Wang
2019-09-06 10:35 ` [dpdk-dev] [PATCH 0/2] add lock-free mode for l3fwd Ananyev, Konstantin
2019-09-09  1:52   ` Ruifeng Wang (Arm Technology China)
2019-09-09 22:45     ` Honnappa Nagarahalli
2019-09-10  6:25       ` Ruifeng Wang (Arm Technology China)
2019-09-11  5:32         ` Honnappa Nagarahalli
2019-09-11  6:18           ` Ruifeng Wang (Arm Technology China)
2019-09-10  9:06     ` Ananyev, Konstantin
2019-09-10  9:56       ` Ruifeng Wang (Arm Technology China)
2019-09-11  5:38         ` Honnappa Nagarahalli
2019-09-11  6:58           ` Ruifeng Wang (Arm Technology China)
2019-09-11  8:35             ` Ananyev, Konstantin
2019-09-16  2:30               ` Ruifeng Wang (Arm Technology China)
2019-11-06 14:03                 ` David Marchand
2019-11-11  5:19                   ` Ruifeng Wang (Arm Technology China)
2019-09-06 17:28 ` Stephen Hemminger
2019-09-09  2:38   ` Ruifeng Wang (Arm Technology China)
2019-09-10 16:27     ` Honnappa Nagarahalli [this message]

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=VE1PR08MB5149CE35529A97B0FCE8ED3D98B60@VE1PR08MB5149.eurprd08.prod.outlook.com \
    --to=honnappa.nagarahalli@arm.com \
    --cc=Gavin.Hu@arm.com \
    --cc=Ruifeng.Wang@arm.com \
    --cc=dev@dpdk.org \
    --cc=nd@arm.com \
    --cc=stephen@networkplumber.org \
    --cc=tomasz.kantecki@intel.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).