* [RFC] mempool: cache preparation
@ 2022-01-21 8:59 Morten Brørup
2022-01-21 9:58 ` Ananyev, Konstantin
0 siblings, 1 reply; 2+ messages in thread
From: Morten Brørup @ 2022-01-21 8:59 UTC (permalink / raw)
To: Olivier Matz, Andrew Rybchenko, Beilei Xing, Jingjing Wu,
Qiming Yang, Qi Zhang, Honnappa Nagarahalli, Thomas Monjalon,
Bruce Richardson
Cc: dev
Some drivers bypass the mbuf/mempool library functions, to manipulate the mempool cache directly for improved performance.
Specifically, the AVX512 implementation of some of the Intel PMDs copy an array of objects from the cache to a field in an array of some structure, i.e. it is not a 1:1 memcpy. This method avoids having to copy the array of pointers into a temporary array before copying them into the fields of the target array, and thus improves performance and reduces CPU cache pollution.
For such purposes, the mempool API could provide functions to prepare the mempool cache for a direct access operation, and commit the transaction:
1. Prepare the cache for getting N objects directly from the objs array. This function returns the address of the position in the cache array, from where the objects can be read, or NULL if failed.
2. Commit after getting the N objects.
3. Prepare the cache for putting N objects directly into the objs array. This function returns the address of the position in the cache array, to where the objects can be written, or NULL if failed.
4. Commit after putting the N objects.
The functions only need to support getting/putting exactly N objects; i.e. the "prepare" functions do not need return a value indicating some number less than N is available. Likewise, the "commit" functions do not need to support any N other than the N in the preceding "prepare" function.
This API extension would provide a clean interface to directly access the mempool cache with high performance, so copy-pasting the mempool's cache handling logic can be avoided, and bugs like [1] would not survive.
Would this be useful?
[1]: https://bugs.dpdk.org/show_bug.cgi?id=923
Med venlig hilsen / Kind regards,
-Morten Brørup
^ permalink raw reply [flat|nested] 2+ messages in thread
* RE: [RFC] mempool: cache preparation
2022-01-21 8:59 [RFC] mempool: cache preparation Morten Brørup
@ 2022-01-21 9:58 ` Ananyev, Konstantin
0 siblings, 0 replies; 2+ messages in thread
From: Ananyev, Konstantin @ 2022-01-21 9:58 UTC (permalink / raw)
To: Morten Brørup, Olivier Matz, Andrew Rybchenko, Xing, Beilei,
Wu, Jingjing, Yang, Qiming, Zhang, Qi Z, Honnappa Nagarahalli,
Thomas Monjalon, Richardson, Bruce
Cc: dev
>
> Some drivers bypass the mbuf/mempool library functions, to manipulate the mempool cache directly for improved performance.
>
> Specifically, the AVX512 implementation of some of the Intel PMDs copy an array of objects from the cache to a field in an array of some
> structure, i.e. it is not a 1:1 memcpy. This method avoids having to copy the array of pointers into a temporary array before copying them
> into the fields of the target array, and thus improves performance and reduces CPU cache pollution.
>
> For such purposes, the mempool API could provide functions to prepare the mempool cache for a direct access operation, and commit the
> transaction:
> 1. Prepare the cache for getting N objects directly from the objs array. This function returns the address of the position in the cache array,
> from where the objects can be read, or NULL if failed.
> 2. Commit after getting the N objects.
> 3. Prepare the cache for putting N objects directly into the objs array. This function returns the address of the position in the cache array, to
> where the objects can be written, or NULL if failed.
> 4. Commit after putting the N objects.
>
> The functions only need to support getting/putting exactly N objects; i.e. the "prepare" functions do not need return a value indicating
> some number less than N is available. Likewise, the "commit" functions do not need to support any N other than the N in the preceding
> "prepare" function.
>
> This API extension would provide a clean interface to directly access the mempool cache with high performance, so copy-pasting the
> mempool's cache handling logic can be avoided, and bugs like [1] would not survive.
>
> Would this be useful?
>
> [1]: https://bugs.dpdk.org/show_bug.cgi?id=923
>
I think it is a very good idea, definitely worth to try.
I am also a bit worried that we have some PMD code that bypasses existing mempool cache functions,
so if we can close the gap here while keeping the perf we have - would be great.
Thanks
Konstantin
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2022-01-21 9:59 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-21 8:59 [RFC] mempool: cache preparation Morten Brørup
2022-01-21 9:58 ` Ananyev, Konstantin
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).