jamal wrote:
On Sat, 2006-04-11 at 09:29 -0800, Ben Greear wrote:
You can ofcourse add many of these based on other header info.
It seems to me your magic header is inside the UDP packet, correct?
In that case you will have to play with matches since you can specify
arbitraty offsets and values inside the packet.
Yes, I want to be able to randomize source/dest MAC, IP, and IP Port, so
I need to match only on the
magic cookie. I'll soon add support to deal with TCP packets as well,
but that is only going to require
calculating a different offset to look for the magic value.
Of course you can do this from your application instead of using tc.
I think that will be the best place to control this and sync with
pktgen sending.
You mean the equiv of calling system(tc filter .....) from the app, or
do you mean something else
entirely?
the rest can be in a method
called after you match in your script?
If the packet/byte counters that the drop action provides are not good
enough, you can write yourself a little module that will do the
accounting the way you want it. For example this will be necessary to
the out-of-sequence cheques below. Timestamps are already being updated
Look at net/sched/act_simple.c and its associated user space code in
iproute2.
Now, Ben - are you listening really this time or am i wasting my time
for the nth time giving you all these details? ;->
You always give details that are pertinent to your setup and not to
mine, and you
always have some 'small' step that is 'write a kernel module and hack on
tc' if you
want it to do something other than the generic thing.
If you are listening then start with:
1) Do a simple test with just udp traffic as above, doing simple
accounting. This helps you to get a feel on how things work.
2) modify the matching rules to match your magic cookie
These first two do not look too difficult. I certainly need more
control/stats than
what the generic counters would be, however, so I assume I need to move
to step 3.
3) write a simple action invoked by your matching rules and use tc to
add it to the policy.
I have exactly no idea of what you mean by this. How do I get this tc
framework to
send the packet with 32-bit value FOO at offset X to some method called
pktgen_rx_pkt(skb)
in the pktgen module? That is all I want in a hook: The ability to
match on a pkt and send it
to my kernel module and to let my kernel module and have it traverse the
stack no farther
unless my kernel module decides to re-insert it for some reason.
If this takes significant work, then please don't waste more time trying
to talk me
into this, as my small patch to dev.c already does exactly what I need
and the code
is very easy to understand.
If this is easy, how about you write the module and make the tc
changes. I'll work on any
changes needed in pktgen and polish up a nice patch for Robert et
al.... Then you can get
the latency distributions, OOO, Dup, Dropped and other counters that my
pktgen logic
provides for your own testing purposes...
Thanks,
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
