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.
On Tue, Aug 8, 2017 at 6:49 AM, Andrew 👽 Yourtchenko <ayour...@gmail.com>
> 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
> 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.
> vpp-dev mailing list
vpp-dev mailing list