> >> I have added macros to help find the parameters and I have added mempool > >> functions that allow you to determine if you can use the mempool and > >> what params it needs. The new mempool functions are mentioned in the > >> docs for ptr compress. > >> Please take a look at v11. > > > > Great, thanks. > > Will try to have a look in next few days. > > With these functions in place, can we produce a unit-test that > > will use together these new mempool functions and compress API? > > Something like: > > - allocate mempool > > - deduce base_pointer for it > > - main_loop_start: > > producer(s): mempool_get(); <fill mbuf with some values>; > > ring_enqueue(); > > consumer(s): ring_dequeue(); <read_and_check_mbuf_data>; mempool_put(); > > - main_loop_end > > - free mempool > > The v11 already includes mempool base pointer and range calculation in > the mempool test and the functions are mentioned in the ptr compress lib > docs. The ptr compress test doesn't use a mempool to minimise dependencies.
Sorry, but I didn't get it: why adding mempool dependency for the unit-test suddenly become a problem? From other side - you are introducing a new library and new API for mempool to enable this new lib. From my perspective it is essential to provide a unit-test (or sample app) to: - do a proper functional (ensure that compress/decompress doesn't corrupt pointers) and performance testing. - demonstrate how this 2 things (new lib and new mempool API) can(/should) be used together. > > I have a v12 pending (awaiting internal reviews) that addresses Morten's > comments (adds prefix, adds tests and doxygen for all the macros, uses > rte_bitops) and a fix for the guide which had the wrong letter case for > the MACRO.
