On Fri, Jan 26, 2024 at 10:55:48AM -0500, Aaron Conole wrote: > Simon Horman <ho...@ovn.org> writes: > > > On Thu, Jan 25, 2024 at 12:05:29PM -0500, Aaron Conole wrote: > >> From: Kevin Sprague <ksprague0...@gmail.com> > >> > >> During normal operations, it is useful to understand when a particular flow > >> gets removed from the system. This can be useful when debugging performance > >> issues tied to ofproto flow changes, trying to determine deployed traffic > >> patterns, or while debugging dynamic systems where ports come and go. > >> > >> Prior to this change, there was a lack of visibility around flow > >> expiration. > >> The existing debugging infrastructure could tell us when a flow was added > >> to > >> the datapath, but not when it was removed or why. > >> > >> This change introduces a USDT probe at the point where the revalidator > >> determines that the flow should be removed. Additionally, we track the > >> reason for the flow eviction and provide that information as well. With > >> this change, we can track the complete flow lifecycle for the netlink > >> datapath by hooking the upcall tracepoint in kernel, the flow put USDT, and > >> the revaldiator USDT, letting us watch as flows are added and removed from > >> the kernel datapath. > >> > >> This change only enables this information via USDT probe, so it won't be > >> possible to access this information any other way (see: > >> Documentation/topics/usdt-probes.rst). > >> > >> Also included is a script (utilities/usdt-scripts/flow_reval_monitor.py) > >> which serves as a demonstration of how the new USDT probe might be used > >> going forward. > >> > >> Signed-off-by: Kevin Sprague <ksprague0...@gmail.com> > >> Co-authored-by: Aaron Conole <acon...@redhat.com> > >> Signed-off-by: Aaron Conole <acon...@redhat.com> > > > > Hi Aaron, > > > > has any consideration been given to adding tests for this feature? > > I don't think so. Actually, we don't have any tests for any of the USDT > probes / scripts. At the very least, we could probably update some of > the existing tests to take advantage of these tracepoints to verify the > information being captured. That's a much bigger task, though.
Thanks Aaron, I understand your point that this is a bigger task. And I have no objections to treating it as a follow-up. > Maybe Adrian has opinions on it as well, since Retis may use this > information to gather insights. > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
