diff options
| author |   Jon Loeliger <jdl@netgate.com> | 2020-10-15 14:41:36 -0400 |
|---|---|---|
| committer |   Damjan Marion <dmarion@me.com> | 2020-12-15 15:14:05 +0000 |
| commit | 5c1e48c01b50ddbd7623228e3dbc94d835d23813 (patch) | |
| tree | c38d75e9f471b5dbee8968230c5f0bf538f2d53e /src/tools/vppapitrace | |
| parent | 510aaa8911843206f7b9ff48b41e3c7b8c4a99fe (diff) | |
classify: add pcap/trace classfier mgmt API calls
Add lookup/get/set API calls to manage both PCAP and Trace
filtering Classifier tables.
The "lookup" call may be used to identify a Classifier table
within a chain of tables taht matches a particular mask vector.
For efficiency, this call should be used to determine to which
table a match vector should be added.
The "get" calls return the first table within a chain (either
a PCAP or the Trace) set of tables. The "set" call may be
used to add a new table to one such chain. If the "sort_masks"
flag is set, the tables within the chain are ordered such that
the most-specific mask is first, and the least-specific mask
is last. A call that "sets" a chain to ~0 will delete and free
all the tables with a chain.
The PCAP filters are per-interface, with "local0", (that is,
sw_if_index == 0) holding the system-wide PCAP filter.
The Classifier used a reference-counted "set" for each PCAP
or trace filter that it stored. The ref counts were not used,
and the vector of tables was only used temporarily to establish
a sorted order for tables based on masks. None of that
complexity was actually warranted, and where it was used,
the same could be achieved more simply.
Type: refactor
Signed-off-by: Jon Loeliger <jdl@netgate.com>
Change-Id: Icc56116cca91b91c631ca0628e814fb53f3677d2
Diffstat (limited to 'src/tools/vppapitrace')
0 files changed, 0 insertions, 0 deletions