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,
-Ben
Thanks,
Mathieu
_______________________________________________
ltt-dev mailing list
[email protected]
http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
