On 24/10/10 09:38 PM, Mathieu Desnoyers wrote:
* Benjamin Poirier ([email protected]) wrote:
On 22/10/10 04:26 PM, Mathieu Desnoyers wrote:
Hi Benjamin,
Can you explain why you need two receive tracepoints in the recv path ?
One tracepoint is in netif_rx() and is fired by drivers that use the
pre-NAPI receive path. The other tracepoint is in netif_receive_skb()
and is fired by drivers that use the NAPI receive path.
"The receive tracepoint is moved earlier in the netif_receive_skb() function.
The tracepoint is also duplicated in the netif_rx() function. This enables
more precise measurements for pre-NAPI drivers."
@@ -2518,9 +2520,13 @@ int netif_rx(struct sk_buff *skb)
if (netpoll_rx(skb))
return NET_RX_DROP;
+ trace_net_dev_receive(skb);
+
if (netdev_tstamp_prequeue)
net_timestamp_check(skb);
+ trace_net_dev_receive(skb);
The side-effect is that two events will be generated for each packet, no ?
No. Depending on the receive path, only one of the two tracepoints is
hit. netif_rx() is specific to pre-NAPI drivers. It eventually leads to
__netif_receive_skb() and therefore avoids the tracepoint in
netif_receive_skb(). NAPI drivers just don't call netif_rx() and
therefore avoid the tracepoint in there.
It would be possible to have only one tracepoint in
__netif_receive_skb() but that would make the event be generated later
on the receive path (in all cases). One of the goals when tracing packet
reception is to get a timestamp as close as possible to the packet
arrival.
Hope this clears things up,
Not really. What I am saying here is that the instrumentation in "netif_rx()"
really calls "trace_net_dev_receive(skb);" *twice*. Once before the call to
"net_timestamp_check(skb)" and once after. I really think it is an
implementation error (or maybe a patch merge error somewhere).
Yeah, that patch hunk looks wonky. The one in the before-last version
(.232) of the kernel.org lttng repository is fine though.
So all pre-NAPI receive paths which call into netif_rx will call the
net_dev_receive event twice logically here, no ?
Thanks,
Mathieu
_______________________________________________
ltt-dev mailing list
[email protected]
http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
