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.


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
> 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

Reply via email to