* Ring library optimization idea
@ 2023-08-20 9:23 Morten Brørup
2023-08-21 4:40 ` Honnappa Nagarahalli
0 siblings, 1 reply; 3+ messages in thread
From: Morten Brørup @ 2023-08-20 9:23 UTC (permalink / raw)
To: dev; +Cc: honnappa.nagarahalli, konstantin.v.ananyev
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?
-Morten
^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: Ring library optimization idea
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
0 siblings, 1 reply; 3+ messages in thread
From: Honnappa Nagarahalli @ 2023-08-21 4:40 UTC (permalink / raw)
To: Morten Brørup, dev
Cc: konstantin.v.ananyev, Wathsala Wathawana Vithanage, nd, nd
> -----Original Message-----
> From: Morten Brørup <mb@smartsharesystems.com>
> Sent: Sunday, August 20, 2023 4:24 AM
> To: dev@dpdk.org
> Cc: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>;
> konstantin.v.ananyev@yandex.ru
> Subject: Ring library optimization idea
>
> 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.
>
> -Morten
^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: Ring library optimization idea
2023-08-21 4:40 ` Honnappa Nagarahalli
@ 2023-08-21 10:19 ` Konstantin Ananyev
0 siblings, 0 replies; 3+ messages in thread
From: Konstantin Ananyev @ 2023-08-21 10:19 UTC (permalink / raw)
To: Honnappa Nagarahalli, Morten Brørup, dev
Cc: konstantin.v.ananyev, Wathsala Wathawana Vithanage, nd, nd
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-08-21 10:19 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 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).