Hi Andrew, As long as you mention issues in acl plugin, I found something strange in bihash_40_8.h: there is no definition of BIHASH_KVP_CACHE_SIZE. So when you get to bihash_template.h, that will be obtaining BIHASH_KVP_CACHE_SIZE from whatever bihash_x_y.h happens to be last in the included header files. I don't know the operational ramifications, but it is not pretty to look at! Can you confirm my observation? I am looking at master.
Burt On Tue, Aug 8, 2017 at 6:49 AM, Andrew 👽 Yourtchenko <ayour...@gmail.com> wrote: > Hi all, > > Just a heads-up: I am currently working on a few issues in acl-plugin > that the system testing as part of the open stack setup has uncovered, > one of them was a memory corruption in the new hash-table based > matching code. Those are always a pain to debug also because they of > course can trip up a completely different part of code than what > caused it. > > So, as part of the of the fix (https://gerrit.fd.io/r/#/c/7928/ & > https://gerrit.fd.io/r/#/c/7817/) , I also moved the ACL plugin to use > its own heap (actually two: one for the new "hash-table match" stuff, > and one for all the rest (including the sessions). This is to improve > the isolation with the other parts of VPP and simplify triage - in > theory, now anything caused by acl-plugin should affect just the > ACL-plugin. > > It was a big-ish patch for a stable branch, but I decided the > serviceability win is very well worth it. > > I've added the "show acl-plugin memory" command which tells about the > state of affairs in those heaps. > > --a > _______________________________________________ > vpp-dev mailing list > vpp-dev@lists.fd.io > https://lists.fd.io/mailman/listinfo/vpp-dev >
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
