All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konstantin Ananyev <konstantin.ananyev@huawei.com>
To: "Honnappa Nagarahalli" <Honnappa.Nagarahalli@arm.com>,
	"Morten Brørup" <mb@smartsharesystems.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: "konstantin.v.ananyev@yandex.ru" <konstantin.v.ananyev@yandex.ru>,
	Wathsala Wathawana Vithanage <wathsala.vithanage@arm.com>,
	nd <nd@arm.com>, nd <nd@arm.com>
Subject: RE: Ring library optimization idea
Date: Mon, 21 Aug 2023 10:19:11 +0000	[thread overview]
Message-ID: <9bb4e5524ca94cc59f652db50ae4d1ee@huawei.com> (raw)
In-Reply-To: <DBAPR08MB58146FFCA80BF6CC0869A72D981EA@DBAPR08MB5814.eurprd08.prod.outlook.com>


Hi Morten,

> > Most of the fast path ring library functions access the two cache lines containing
> > respectively the r->prod and r->cons structures.
> >
> > Some of the fast path functions also have to fetch r->capacity and r->mask,
> > which reside in another cache line.
> >
> > What do you think about adding shadow variables of r->capacity and r->mask
> > to the same cache line as r->prod, to improve ring library performance (by
> > avoiding having to read a third cache line) when under CPU cache pressure?
> Agree with the idea. I am not sure about the performance as these are read-only data. IMO, we should not worry about it as it saves
> one cache line (but we do not need to measure the performance). They will occupy 12B, but I do not see how we will occupy the
> entire 64B of the cacheline in the near future.
> 
> Also, the shadow variables need to be part of both r->prod and r->cons.

Personally, I think that for majority of cases the perf gain with be either tiny or none.
From other side, I don't see any harm with that approach, as Honnapa said, we
do should have space for that in prod/cons cache-lines.
So, no objections from me in general.
Thanks
Konstantin

 


      reply	other threads:[~2023-08-21 10:19 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-20  9:23 Ring library optimization idea Morten Brørup
2023-08-21  4:40 ` Honnappa Nagarahalli
2023-08-21 10:19   ` Konstantin Ananyev [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=9bb4e5524ca94cc59f652db50ae4d1ee@huawei.com \
    --to=konstantin.ananyev@huawei.com \
    --cc=Honnappa.Nagarahalli@arm.com \
    --cc=dev@dpdk.org \
    --cc=konstantin.v.ananyev@yandex.ru \
    --cc=mb@smartsharesystems.com \
    --cc=nd@arm.com \
    --cc=wathsala.vithanage@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.