[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20181117.221921.901866732366630755.davem@davemloft.net>
Date: Sat, 17 Nov 2018 22:19:21 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: mathieu.desnoyers@...icios.com
Cc: gbastien@...satic.net, netdev@...r.kernel.org, rostedt@...dmis.org,
mingo@...hat.com
Subject: Re: [PATCH v3] net: Add trace events for all receive exit points
From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Date: Sat, 17 Nov 2018 13:27:29 -0500 (EST)
> I see two possible solutions:
>
> 1) Remove the "skb" argument from the sbk_exit tracepoints completely.
> Anyway, I think it's not really needed for analysis purposes because
> we can link the "entry" with the associated "exit" using the thread ID
> executing those tracepoints. (Geneviève, would that work for your
> analyses ?)
>
> 2) Move the skb_exit tracepoints before freeing the skb pointer. My
> concern here is that the instrumentation may become much uglier than
> the currently proposed patch. (I have not looked at the specifics
> though, so I may be wrong.)
>
> Do you have a preference between those two approaches, or perhaps you
> have an alternative solution in mind ?
I wonder how other situations handle this.
About #2, if you put the tracepoint beforehand you can't log the
'ret' value. So at least in that regard I prefer #1.
If tracepoints generally handle this by matching up the thread
ID, then definitely that's how we should do it here too instead
of trying to use the SKB pointer for this purpose.
Powered by blists - more mailing lists