[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <871q8ngesa.fsf@waldekranz.com>
Date: Wed, 06 Mar 2024 23:45:57 +0100
From: Tobias Waldekranz <tobias@...dekranz.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Paolo Abeni <pabeni@...hat.com>, davem@...emloft.net, kuba@...nel.org,
roopa@...dia.com, razor@...ckwall.org, bridge@...ts.linux.dev,
netdev@...r.kernel.org, jiri@...nulli.us, ivecera@...hat.com,
mhiramat@...nel.org, linux-trace-kernel@...r.kernel.org
Subject: Re: [PATCH v3 net-next 4/4] net: switchdev: Add tracepoints
On ons, mar 06, 2024 at 16:46, Steven Rostedt <rostedt@...dmis.org> wrote:
> On Wed, 06 Mar 2024 21:02:06 +0100
> Tobias Waldekranz <tobias@...dekranz.com> wrote:
>
>> On ons, mar 06, 2024 at 10:15, Steven Rostedt <rostedt@...dmis.org> wrote:
>> > On Mon, 04 Mar 2024 23:40:49 +0100
>> > Tobias Waldekranz <tobias@...dekranz.com> wrote:
>> >
>> >> On ons, feb 28, 2024 at 09:56, Steven Rostedt <rostedt@...dmis.org> wrote:
>> >> > On Wed, 28 Feb 2024 11:47:24 +0100
>> >> > Tobias Waldekranz <tobias@...dekranz.com> wrote:
>> >> >
>> >> > The "trace_seq p" is a pointer to trace_seq descriptor that can build
>> >> > strings, and then you can use it to print a custom string in the trace
>> >> > output.
>> >>
>> >> Yes I managed to decode the hidden variable :) I also found
>> >> trace_seq_acquire() (and its macro alter ego __get_buf()), which would
>> >> let me keep the generic stringer functions. So far, so good.
>> >>
>> >> I think the foundational problem remains though: TP_printk() is not
>> >> executed until a user reads from the trace_pipe; at which point the
>> >> object referenced by __entry->info may already be dead and
>> >> buried. Right?
>> >
>> > Correct. You would need to load all the information into the event data
>> > itself, at the time of the event is triggered, that is needed to determine
>> > how to display it.
>>
>> Given that that is quite gnarly to do for the events I'm trying to
>> trace, because of the complex object graph, would it be acceptable to
>> format the message in the assign phase and store it as dynamic data?
>> I.e., what (I think) you suggested at the end of your first response.
>
> It's really up to what you want to do ;-)
Alright. I'll interpret that as "there's a >0% chance that I'll give you
an Acked-by on something like that" :)
>>
>> My thinking is:
>>
>> - Managing a duplicate (flattened) object graph, exclusively for use by
>> these tracepoints, increases the effort to keep the tracing in sync
>> with new additions to switchdev; which I think will result in
>> developers simply avoiding it altogether. In other words: I'd rather
>> have somewhat inefficient but simple flashlight, rather than a very
>> efficient one that no one knows how to change the batteries in.
>>
>> - This is typically not a very hot path. Most events are triggered by
>> user configuration. Otherwise when new neighbors are discovered.
>>
>> - __entry->info is still there for use by raw tracepoint consumers from
>> userspace.
>
> How big is this info?
The common struct (switchdev_notifier_info) is 24B at the
moment. Depending on __entry->val, the size of the enclosing
notification (e.g. switchdev_notifier_port_obj_info) is between
40-64B. This pattern may then repeat again inside the concrete notifier,
where you have a pointer to a common object (e.g. switchdev_obj, 48B)
whose outer size (e.g. switchdev_obj_port_vlan, 56B) is determined by an
accompanying enum.
Powered by blists - more mailing lists