Open stefanheule opened 5 years ago
One way to get this type of stats is by using P4 direct counters for the tables you are interested in. Is anything preventing you from doing that?
Yes, the direct_counter in v1model is made for exactly that. You could have #ifdef'd code for constructing such counters and having counters = table_foo_direct_counter;
table properties in your tables, only when some particular "extra stats" symbol was #define'd, and #undef it when you didn't need those counters there.
One detail to check -- I do not know if simple_switch's implementation of direct_counter maintains stats for table apply calls that result in a miss. You would get somewhat higher test coverage if you maintained such counts, too, as long as those counts could be compared against some expected value for those.
bmv2 includes an event logger that generates a PUB SUB message for each notable event (such as a table hit / miss); it was designed specifically to test P4 coverage unfortunately this functionality is built with nanomsg
It would be fantastic if bmv2 would export some statistics around the packets it forwarded, such as what tables and entries have been hit and how often. This could for instance be used to get some coverage information around how many of the installed entries have been exercised by a set of packets.
BMv2 already logs a lot of this to stderr, but it is not in an easily consumable format.