summaryrefslogtreecommitdiffstats
path: root/src/plugins/acl/hash_lookup.c
AgeCommit message (Collapse)AuthorFilesLines
2017-09-07acl-plugin: match index set to first portrange element if non-first ↵Andrew Yourtchenko1-5/+1
portrange matches on the same hash key (VPP-937) Multiple portranges that land on the same hash key will always report the match on the first portrange - even when the subsequent portranges have matched. Test escape, so make a corresponding test case and fix the code so it passes. (the commit on stable/1707 has erroneously mentioned VPP-938 jira ticket) Change-Id: Idbeb8a122252ead2468f5f9dbaf72cf0e8bb78f1 Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com> (cherry picked from commit fb088f0a201270e949469c915c529d75ad13353e) Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
2017-08-25acl-plugin: warning printed when acl_add_replace already applied ACLs ↵Andrew Yourtchenko1-17/+38
(complete the fix for VPP-935) The fix for VPP-935 missed the case that hash_acl_add() and hash_acl_delete() may be called during the replacement of the existing applied ACL, as a result the "applied" logic needs to be replicated for the hash acls separately, since it is a lower layer. Change-Id: I7dcb2b120fcbdceb5e59acb5029f9eb77bd0f240 Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com> (cherry picked from commit ce9714032d36d18abe72981552219dff871ff392)
2017-08-10acl-plugin: hash lookup bitmask not cleared when ACL is unapplied from ↵Andrew Yourtchenko1-4/+27
interface (VPP-935) The logic in hash ACL bitmask update was using the vector of ACLs applied to the interface to rebuild the hash lookup mask. However, in transient cases (like doing group manipulation with hash ACLs), that will not hold true. Thus, make a local copy of for which ACL indices the hash_acl_apply was called previously, and maintain that one local to the hash_lookup.c file logic. Change-Id: I30187d68febce8bba2ab6ffbb1eee13b5c96a44b Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com> (cherry picked from commit 1de7d7044434196610190011ebb431f054701259)
2017-08-10acl-plugin: avoid crash in multithreaded setup adding/deleting ACLs with ↵Andrew Yourtchenko1-0/+29
traffic (VPP-910/VPP-929) The commit fixing the VPP-910 and separating the memory operations into separate heaps has missed setting the MHEAP_FLAG_THREAD_SAFE, which quite obviously caused the issues in the multithread setup. Fix that. Also, add the debug CLIs "set acl-plugin heap {main|hash} {validate|trace} {1|0}" to toggle the memory instrumentation, in case we ever need it in the future. Change-Id: I8bd4f7978613f5ea75a030cfb90674dac34ae7bf Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com> (cherry picked from commit e6423bef32ca2ffcfcd7a092eb4673badd53ea4c)
2017-08-08acl-plugin: rework the optimization 7383, fortify acl-plugin memory behavior ↵Andrew Yourtchenko1-102/+151
(VPP-910) The further prolonged testing from testbed that reported VPP-910 has uncovered a couple of deeper issues with optimization from 7384, and the usage of subscripts rather than vec_elt_at_index() allowed to hide a couple of further errors in the code. Also, the current acl-plugin behavior of using the global heap for its dynamic data is problematic - it makes the troubleshooting much harder by potentially spreading the problem around. Based on this experience, this commits makes a few changes to fix the issues seen, also improving the serviceability of the acl-plugin code for the future: - Use separate mheaps for any ACL-related control plane operations and separate for the hash lookup datastructures, to compartmentalize any memory-related issues for the ACL plugin. - Ensure vec_elt_at_index() usage throughout the hash_lookup.c file. - Use vectors rather than raw memory for storing the "ordinary" ACL rules. - Rework the optimization from 7384 to use a separate tail pointer rather than overloading the "prev" field. - Make get_session_ptr() more conservative and adjust is_valid_session_ptr accordingly Change-Id: Ifda85193f361de5ed3782a4acd39622bd33c5830 Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com> (cherry picked from commit bd9c5ffe39e9ce61db95d74d150e07d738f24da1)
2017-07-20acl-plugin: assertion failed at hash_lookup.c:226 when modifying ACLs ↵Andrew Yourtchenko1-0/+11
applied as part of many (VPP-910) change 7385 has added the code which has the first ACE's "prev" entry within the linked list of shadowed ACEs pointing to the last ACE, in order to avoid the frequent linear list traversal. That change was not complete and did not update this "prev" entry whenever the last ACE was deleted. As a result the changes within the applied ACLs which caused the calls to hash_acl_unapply/hash_acl_apply may result in hitting assert which does the sanity check. The solution is to add the missing update logic. Change-Id: I9cbe9a7c68b92fa3a22a8efd11b679667d38f186 Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com> (cherry picked from commit 45fe7399152f5ca511ba0b03fee3d5a3dffd1897)
2017-07-04acl-plugin: VPP-897: applying of large number of ACEs is slowAndrew Yourtchenko1-18/+39
When applying ACEs, in the new hash-based scheme, for each ACE the lookup in the hash table is done, and either that ACE is added to the end of the existing list if there is a match, or a new list is created if there is no match. Usually ACEs do not overlap, so this operation is fast, however, the fragment-permit entries in case of a large number of ACLs create a huge list which needs to be traversed for every other ACE being added, slowing down the process dramatically. The solution is to add an explicit flag to denote the first element of the chain, and use the "prev" index of that element to point to the tail element. The "next" field of the last element is still ~0 and if we touch that one, we do the linear search to find the first one, but that is a relatively infrequent operation. Change-Id: I352a3becd7854cf39aae65f0950afad7d18a70aa Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com> (cherry picked from commit 204cf74aed51ca07933df7c606754abb4b26fd82)
2017-06-19acl-plugin: bihash-based ACL lookupAndrew Yourtchenko1-0/+742
Add a bihash-based ACL lookup mechanism and make it a new default. This changes the time required to lookup a 5-tuple match from O(total_N_entries) to O(total_N_mask_types), where "mask type" is an overall mask on the 5-tuple required to represent an ACE. For testing/comparison there is a temporary debug CLI "set acl-plugin use-hash-acl-matching {0|1}", which, when set to 0, makes the plugin use the "old" linear lookup, and when set to 1, makes it use the hash-based lookup. Based on the discussions on vpp-dev mailing list, prevent assigning the ACL index to an interface, when the ACL with that index is not defined, also prevent deleting an ACL if that ACL is applied. Also, for the easier debugging of the state, there are new debug CLI commands to see the ACL plugin state at several layers: "show acl-plugin acl [index N]" - show a high-level ACL representation, used for the linear lookup and as a base for building the hashtable-based lookup. Also shows if a given ACL is applied somewhere. "show acl-plugin interface [sw_if_index N]" - show which interfaces have which ACL(s) applied. "show acl-plugin tables" - a lower-level debug command used to see the state of all of the related data structures at once. There are specifiers possible, which make for a more focused and maybe augmented output: "show acl-plugin tables acl [index N]" show the "bitmask-ready" representations of the ACLs, we well as the mask types and their associated indices. "show acl-plutin tables mask" show the derived mask types and their indices only. "show acl-plugin tables applied [sw_if_index N]" show the table of all of the ACEs applied for a given sw_if_index or all interfaces. "show acl-plugin tables hash [verbose N]" show the 48x8 bihash used for the ACL lookup. Change-Id: I89fff051424cb44bcb189e3cee04c1b8f76efc28 Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>