Hi Patrick!
I greatly appreciate all your questions, comments, explanations ..
please keep asking and giving me as much insight as you please.
I really want to do something good, accurate, useful to everyone
and as professional as possible.
>> - because it would jump to 'ip_packet_match( )',
>Yes.
>> - run the IP address code first (and find no match),
>Yes.
>> - then the interface (find the match),
>Yes.
>> - and then jump again to 'ip_packet_match( )' to find matches for IP
addrss
>No. How did you come to this conclusion?
Well, if the code finds a match on 'ip_packet_match ( )' for the interface
it returns 0.
Then it will jump to the 'else statement' that contains the "no_match: "
code
but the loop is still going to run because the 'hotdrop' variable is still
0,
it has no changed, or has it?
how does it break out of the loop then?
I am probably wrong, but I just don't see how it breaks out of the loop
immediately
if the ip_packet_match(...) = = 0. I'm using iptables version 1.2.4. I
don't
know if its different in 1.2.5 or 1.2.6 versions.
-----
(Patrick wrote:)
>I would love to see both the results, and your timestamp catching and
>gathering patches. The latter would be most interesting, because it
>would allow reproduction of the results on different platforms, and
>under different rulesets.
Concerning the code to make the timestamps... I've gotta trim it a bit
because
it might not be the 'most efficient' piece of code. I had to save lots of
variables
in structures to be able to put it in the /proc and read what the sk_buff
contained
... though I can paste "as is" for comments... you can rip it appart!
I would really like to improve my coding !!
---
>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?
Well, it would be nice to be able to add that kind of functionality..in that
way you have a portable and standard way to test the firewall. For the
implementation you describe... I got a question?
Say that the test is performed in an isolated network, no services
running on neither the DUT or the packet generator PC. If I wish to
time only TCP packets... How do you differentiate an inexpected 'ARP'
from a TCP packet?
Example: For my tests, I have marked my payload in order to time
only the TCP/UDP packets that I send. I've marked them like this:
"AAAAA ..... EEEEE", beginning and end of the payload, respectively. On
the DUT side, I filter and take the timestamp
( eg. @ netif_rx( ):
if skb->data[52] == 0xaa
&& skb->data[53] = = 0xaa
&& skb->data[skb->len-1]= = 0xee
&& skb->data[skb->len-4] = = 0xee) {
...
TAKE TIMESTAMP (rdtscl)
}
I do this at every layer (except for socket.c)
Well... Hmmm... I guess that the complexity of the new kernel code depends
on what is exactly that we want to understand? is it the latency for any
incoming
traffic depending on the number of rules? or maybe we want to find out
the threshold of how many rules can we add until we start dropping packets?
Interesting!! I'll keep thinking about it!
Thanks again,
Americo
