Ben Greear writes:
> > Changes:
> > * use a nano-second timer based on the scheduler timer (TSC) for relative
> > times, instead of get_time_of_day.
Seems I missed to set tsc as clocksource. It makes a difference. Performance is
normal and I'm less confused.
e1000 82546GB @ 1.6 GHz Opteron.
jamal writes:
> 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
> 3) write a simple action invoked by your mat
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 v
On Sat, 2006-04-11 at 09:29 -0800, Ben Greear wrote:
> jamal wrote:
> Please do send a script. I match based on this method below. Probably
> you only
> need the part that checks for the MAGIC,
What i do in my case is send to the SUT to UDP port 9. The SUT loops
back the packet to me afte
jamal wrote:
On Wed, 2006-01-11 at 11:11 -0800, Ben Greear wrote:
I'd be thrilled to have the receive logic go into pktgen, even if
it was #if 0 with a comment
showing how to patch dev.c to get it working. It would make my
out-of-tree patch smaller
and should help others who are doing res
On Wed, 2006-01-11 at 11:11 -0800, Ben Greear wrote:
> I'd be thrilled to have the receive logic go into pktgen, even if
> it was #if 0 with a comment
> showing how to patch dev.c to get it working. It would make my
> out-of-tree patch smaller
> and should help others who are doing research and
Robert Olsson wrote:
Ben Greear writes:
> It requires a hook in dev.c, or at least that is the only way I can
> think to implement it.
Well the hook be placed along the packet path even in drivers. In tulip I didn't
even take packet of the ring in some experiments.
And there plenty of e
Ben Greear writes:
> It requires a hook in dev.c, or at least that is the only way I can
> think to implement it.
Well the hook be placed along the packet path even in drivers. In tulip I
didn't
even take packet of the ring in some experiments.
And there plenty of existing hooks already i
Robert Olsson wrote:
Ben Greear writes:
> I'd be thrilled to have the receive logic go into pktgen, even if it was #if
0 with a comment
> showing how to patch dev.c to get it working. It would make my out-of-tree
patch smaller
> and should help others who are doing research and driver deve
Ben Greear writes:
> I'd be thrilled to have the receive logic go into pktgen, even if it was #if
> 0 with a comment
> showing how to patch dev.c to get it working. It would make my out-of-tree
> patch smaller
> and should help others who are doing research and driver development...
Ju
Robert Olsson wrote:
Ben Greear writes:
> I've completed the first pass of my changes to pktgen in 2.6.18.
> Many of these features are probably DOA based on previous conversations,
> but perhaps this will help someone
Thanks. Well sometimes there is a need to capture and drop pkts and v
11 matches
Mail list logo
