Move __str__ to super for all subclasses of VppObject
Implement __repr__ in VppObject
Implement __hash__ and __eq__
Change-Id: Ibd4ea37b84b17f499ab86630fb5b9ed9c8b4b1c2
Signed-off-by: Paul Vinciguerra <pvinci@vinciconsulting.com>
They mask dependencies and confuse third party tools.
Change-Id: I24ee16bfa0d746a8e8cb99891ba8b20523048b69
Signed-off-by: Paul Vinciguerra <pvinci@vinciconsulting.com>
1) stats are accessed via the stat segment which is more condusive to
monitoring
2) stats are accurate in the presence of multiple threads. There's no
guarantee that an SA is access from only one worker.
Change-Id: Id5e217ea253ddfc9480aaedb0d008dea031b1148
Signed-off-by: Neale Ranns <nranns@cisco.com>
in the same maaner as with other tunnel tyeps we use
the FIB to cache and track the destination used to reach
the tunnel endpoint. Post encap we can then ship the packet
straight to this adjacency and thus elide the costly second
lookup.
- SA add and del function so they can be used both directly
from the API and for tunnels.
- API change for the SA dump to use the SA type
- ipsec_key_t type for convenience (copying, [un]formating)
- no matching tunnel counters in ipsec-if-input
Change-Id: I9d144a59667f7bf96442f4ca66bef5c1d3c7f1ea
Signed-off-by: Neale Ranns <nranns@cisco.com>
- return the stats_index of each SPD in the create API call
- no ip_any in the API as this creates 2 SPD entries. client must add both v4 and v6 explicitly
- only one pool of SPD entries (rhter than one per-SPD) to support this
- no packets/bytes in the dump API. Polling the stats segment is much more efficient
(if the SA lifetime is based on packet/bytes)
- emit the policy index in the packet trace and CLI commands.
Change-Id: I7eaf52c9d0495fa24450facf55229941279b8569
Signed-off-by: Neale Ranns <nranns@cisco.com>
- use enums to enumerate the algoritms and protocols that are supported
- use address_t types to simplify encode/deocde
- use typedefs of entry objects to get consistency between add/del API and dump
Change-Id: I7e7c58c06a150e2439633ba9dca58bc1049677ee
Signed-off-by: Neale Ranns <nranns@cisco.com>
