* 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). So all pre-NAPI receive paths which call into netif_rx will call the net_dev_receive event twice logically here, no ? Thanks, Mathieu -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com _______________________________________________ ltt-dev mailing list [email protected] http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
