13:29 <fnordahl> anyone seen curious jump in resident memory size when linking with DPDK 24.11? we're struggling to get a snapshot of OVS w/DPDK 24.11 to pass tests due to what appears a 10x growth in resident memory size just by linking to DPDK

13:31 <fnordahl> specifically the "monitor-cond-change with many sessions pending" test stands out, as it's running a 1000 copies of ovsdb-client, and the growth from 2048 to 20048 resident size brings it above test runner constraints

13:34 <dmarchand> there is indeed a change that increased memory consumption, but on the other hand, do you really need to link ovsdb-client with dpdk ?

13:34 <fnordahl> dmarchand: that is a good question. OVS's build system appears to do so currently

13:35 <fnordahl> If it's expected behavior from dpdk I guess we should visit the need for that linking, I'll take a look

13:36 <dmarchand> it is likely due to 5bce9bed67ad ("eal: add static per-lcore memory allocation facility")

13:37 <fnordahl> Yeah, that feature did indeed stand out in the release notes

13:37 <dmarchand> I later reduced this to 128k (after objection from author), though I would have made it 4k..

13:40 <dmarchand> another option I had in store, was to move this allocation out of a constructor (here, this is some x86 power intrinsics code that allocates strucutres), and instead invoke in rte_eal_init

13:41 <fnordahl> that does indeed sound compelling, that way it would only affect linked binaries that actually init the library

13:50 <fnordahl> Will track this in https://launchpad.net/bugs/2090931 for now, so that we can push forward with tests to help reveal any other issues

15:50 <imaximets> FWIW, dpdk is linked with libopenvswitch, and all OVS binaries are linked against that library.

15:52 <fnordahl> yeah, looking at how the packaging works it appears to provide only ovs-vswitchd from a DPDK-enabled build tree. However the build-time tests are ran for both build-trees. So for now we chose to play a bit with AUTOTEST_PATH to mimic that behavior in the build-time tests and work around the issue.

15:56 <fnordahl> (build time tests using dummy dp beggs to question whether it's worth running them for both trees at all, but removing 3000 tests on a whim is a tad more controversial ;)

16:07 <imaximets> :)

16:08 <imaximets> Either way, this only applies to debian packaging. It doesn't seem reasonable to reserve all that memory for nothing either way as it will be in other distributions or if people are building OVS from sources.