On Sun, Mar 17, 2002 at 10:12:14AM +0100, Harald Welte wrote: > On Sat, Mar 16, 2002 at 03:35:29PM -0800, Americo Melara wrote: > > Where do I take the timestamps to track the packet throughout the stack? > > here: > > 1. netif_rx @ (net/core/dev.c) > > 2. ip_local_deliver @ (net/ipv4/ip_input.c) before it calls NF_HOOK > > 3. ip_local_deliver_finish @ (net/ipv4/ip_input.c) at the beginning of the > > function > > 4. tcp_rcv_established @ (net/ipv4/tcp_input.c) at the end of the function > > 5. sock_recvmsg @ (net/socket.c) before it exits the function > > How do I take timestamps? Specifically using rdtscl( ) but there is a lot > > of code in between to grab other information about the packet (e.g > > 'skb->stamp' used as an ID to match the time with the time as it travels > > throughout the layers) > > so you are benchmarking filtering of local packets? That isn't too > interesting, sorry. Most people are interested in the traditional firewall > case, where packets get forwarded.
Hmm. How would the rule checking process differ in the forwarding and local case, given identical rules? The interesting interval, in Americo's stamping setup above, is between 2. and 3. This should carry over identically to the FORWARD case, wouldn't it? I wish iptables would make such latency measurements itself. My idea is to extend the per-rule byte/packet counters with one additional 64 bit counter. On entry to a chain, rdtsc() stores the current TSC on the stack. Every time a byte/packet counter is incremented, rdtsc() is called again, and the difference to the TSC on the stack is added to the new 64 bit "latency sum" counter. Divide that by the packet counter, and you have the real latency per packet. Perfect profiling. NB, I would like to have a kernel compile option which leaves off the packet/bytecounter updates. Leave the structs alone, just don't update the counters. Any reason why this can't be? best regards Patrick
