Created attachment 93665 [details] Patch to add support for Intel DPDK allocator rte_malloc family Dear Maintainers, Intel's DPDK framework (http://www.dpdk.org/) ships with a custom family of heap allocators with the following signatures: void *rte_malloc(const char *type, size_t size, unsigned align); void *rte_zmalloc(const char *type, size_t size, unsigned align); void *rte_calloc(const char *type, size_t num, size_t size, unsigned align); void *rte_realloc(void *ptr, size_t size, unsigned align); void *rte_malloc_socket(const char *type, size_t size, unsigned align, int socket); void *rte_zmalloc_socket(const char *type, size_t size, unsigned align, int socket); void *rte_calloc_socket(const char *type, size_t num, size_t size, unsigned align, int socket); void rte_free(void *ptr); We are building an application using this framework, and given how amazingly useful Valgrind is, I've created an internal build with a patch to support these allocators, so that we can fully debug our product. What I have done is simply wrap those functions in libc's malloc family. The result seems to work quite well, so I'd like to ask for feedback (especially on whether there are there other, simpler ways to solve this problem!) and, if you like, to contribute back the patch, which is attached (taken from the SVN head). Thank you! Kind regards, Luca Boccassi Brocade Communications Systems
I'm not sure that's safe - you're ignoring the requested alignment (assuming that is what the "align" parameter is) which could easily cause the program to abort if it relies on the alignment being respected. The arena_malloc call and friends only align to 8 bytes (on 32 bit x86, arm and mips platforms) or 16 bytes (on everything else) so if an alignment larger than that was requested it would be chance if you got it or not. Also what does the "socket" argument do and what is the effect of ignoring it?
Hello Tom, (In reply to Tom Hughes from comment #1) > I'm not sure that's safe - you're ignoring the requested alignment (assuming > that is what the "align" parameter is) which could easily cause the program > to abort if it relies on the alignment being respected. > > The arena_malloc call and friends only align to 8 bytes (on 32 bit x86, arm > and mips platforms) or 16 bytes (on everything else) so if an alignment > larger than that was requested it would be chance if you got it or not. Yes, that is my major concern. The application we build uses quite heavily a 64 bytes alignment, but I haven't seen it explode in my face (yet) :-) Do you have any suggestion on how this could be implemented? Any particular area of the Valgrind code I can look at? > Also what does the "socket" argument do and what is the effect of ignoring > it? It's the NUMA socket. DPDK can allocate memory on a specific CPU socket, to improve memory latency (each thread is usually pinned to a specific core). The framework allows the number of NUMA sockets to be a runtime parameter, so I think it's safe to ignore it when running in Valgrind for testing purposes. As far as I know it should not affect correctness, only latency. Thanks for your feedback! Kind regards, Luca Boccassi Brocade Communications Systems
Created attachment 95335 [details] 1 - VALGRIND_NON_SIMD_CALL4 patch
Created attachment 95336 [details] 2 - VALGRIND_NON_SIMD_CALL5 patch
Created attachment 95337 [details] 3 - drd_realloc alignment
Created attachment 95338 [details] 4 - dhat realloc alignment
Created attachment 95339 [details] 5 - h_replace realloc alignment
Created attachment 95340 [details] 6 - hg_cli realloc alignment
Created attachment 95341 [details] 7 - massif realloc alignment
Created attachment 95342 [details] 8 - memcheck realloc alignment
Created attachment 95343 [details] 9 - DPDK (rte_*alloc) family) support
(In reply to Tom Hughes from comment #1) > I'm not sure that's safe - you're ignoring the requested alignment (assuming > that is what the "align" parameter is) which could easily cause the program > to abort if it relies on the alignment being respected. > > The arena_malloc call and friends only align to 8 bytes (on 32 bit x86, arm > and mips platforms) or 16 bytes (on everything else) so if an alignment > larger than that was requested it would be chance if you got it or not. Hi Tom, Found some time to work again on this, apologies for the delay. I have removed the previous patch and split my changes in 9 patches, since in order to support alignment I had to refactor the implementation of the helper functions that the various tools use to implement realloc. Also I added VALGRIND_NON_SIMD_CALL4 and VALGRIND_NON_SIMD_CALL5, since some of the rte_* functions have 4 and 5 parameters. I thought it would be cleaner and nicer to see each refactor in its own patch. They apply cleanly on the current HEAD of SVN. I tested them with some very large alignment values with our DPDK application in Debian stable 64bit and I had no issues.
Forgot to mention, since DPDK is often statically compiled, I added support for that too. Tested by running valgrind with --soname-synonyms=somalloc=NONE