On Mon, 30 Jan 2023 16:50:32 +0100 Petr Machata <[email protected]> wrote:
> Steven Rostedt <[email protected]> writes: > > > On Thu, 26 Jan 2023 18:01:14 +0100 > > Petr Machata <[email protected]> wrote: > > > >> + TP_printk("dev %s af %u src %pI4/%pI6c grp %pI4/%pI6c/%pM vid %u", > >> + __get_str(dev), __entry->af, __entry->src4, __entry->src6, > >> + __entry->grp4, __entry->grp6, __entry->grpmac, __entry->vid) > > > > And just have: > > > > TP_printk("dev %s af %u src %pI6c grp %pI6c/%pM vid %u", > > __get_str(dev), __entry->af, __entry->src, __entry->grp, > > __entry->grpmac, __entry->vid) > > > > As the %pI6c should detect that it's a ipv4 address and show that. > > This means the IP addresses will always be IPv6, even for an IPv4 MDB > entries. One can still figure out the true protocol from the address > family field, but it might not be obvious. Plus the IPv4-mapped IPv6 > addresses are not really formatted as IPv4, though yeah, IPv4 notation > is embedded in that. > > All the information is still there, but... scrambled? Not sure the > reduction in clarity is worth the 8 bytes that we save. The tracepoint > is unlikely to trigger often. 8 bytes per event, and yes, ring buffer real estate is expensive. And if you use trace-cmd or perf, we can always add a plugin to libtraceevent that can format this much nicer based on the information that is there. -- Steve
