- Message d'origine -
De: Mandeep Singh Baines [EMAIL PROTECTED]
Date: Mon, 3 Sep 2007 20:20:36 -0700
Sujet: [PATCH] [sis900] convert to NAPI, WAS Re: pktgen terminating condition
Hi Daniele,
Attached is a patch for converting the sis900 driver to NAPI. Please take a
look at let me know
call to hard_start_xmit would reset the
timer. I could try this for a future patch. Not sure if the extra code
would cost me more than I get back in savings.
I did see a significant boost to tx performance by optimizing start_xmit:
more
than double pps in pktgen.
148Kpps on a slow piece
Baines [EMAIL PROTECTED]
Date: Mon, 3 Sep 2007 20:20:36 -0700
Sujet: [PATCH] [sis900] convert to NAPI, WAS Re: pktgen terminating condition
Hi Daniele,
Attached is a patch for converting the sis900 driver to NAPI. Please take a
look at let me know what you think. I'm not 100% sure if I'm
start_xmit: more
than double pps in pktgen.
I'm also attaching some test results for various iterations of development.
Regards,
Mandeep
Daniele Venzano ([EMAIL PROTECTED]) wrote:
- Message d'origine -
De: jamal [EMAIL PROTECTED]
Date: Fri, 31 Aug 2007 09:50:03 -0400
Sujet: Re: Re: pktgen
- Message d'origine -
De: jamal [EMAIL PROTECTED]
Date: Fri, 31 Aug 2007 09:50:03 -0400
Sujet: Re: Re: pktgen terminating condition
I dont know if you followed the discussion - by defering the freeing of
skbs, you will be slowing down socket apps sending from the local
machine. It may
diff -urNp linux-orig/net/core/pktgen.c linux-mod/net/core/pktgen.c
--- linux-orig/net/core/pktgen.c2007-08-31 02:21:01.0 -0400
+++ linux-mod/net/core/pktgen.c 2007-09-01 20:51:22.0 -0400
@@ -111,6 +111,9 @@
*
* 802.1Q/Q-in-Q support by Francesco Fondelli (FF)
[EMAIL
- Message d'origine -
De: Mandeep Baines [EMAIL PROTECTED]
Date: Wed, 29 Aug 2007 09:59:42 -0700
Sujet: Re: pktgen terminating condition
Looks good to me given the desire. I would bounce it by whoever the
maintainer is - they may have some insights on the lazy tx prune habit.
+ [EMAIL
On Thu, 2007-30-08 at 22:19 -0700, David Miller wrote:
You could implement this quite simply using skb-destructor.
Thats what i was thinking ..
It will add some atomics, so on weaker pktgen source systems
it might decrease the generators rate.
Indeed. So maybe a config option instead
On Fri, 2007-31-08 at 14:17 +0200, Daniele Venzano wrote:
I don't regard the TxOK solution as something usable for mainline, but it has
its
use for the users of pktgen.
I dont know if you followed the discussion - by defering the freeing of
skbs, you will be slowing down socket apps sending
On Wed, 2007-29-08 at 09:59 -0700, Mandeep Baines wrote:
I'll work on a NAPI patch.
It's a GoodThing - go for it.
cheers,
jamal
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Wed, 2007-29-08 at 18:32 +0200, Robert Olsson wrote:
Yes it's synchronization issue... the test is over and we have sent
all pkts to the device but pktgen cannot free the skb for it still
has refcounts.
Ok, right.
I was confusing it with another issue where pktgen could send a lot
From: jamal [EMAIL PROTECTED]
Date: Thu, 30 Aug 2007 08:08:40 -0400
I was confusing it with another issue where pktgen could send a lot of
packets without waiting for them to be freed; there are some drivers
(10G) which may hold onto 8K skbs. A gazillion ooms start spewing ;- My
thinking
:
is that outl(TxENA | inl(ioaddr + cr), ioaddr + cr) really needed on a
per-packet basis? Should it not be sufficient to turn it on once at
open()?
Anyway, if I rewrite the driver to use TxOK instead of TxIdle, pktgen
works fine.
I think its a good thing pktgen caught this; i am unsure however
jamal writes:
On Tue, 2007-28-08 at 21:43 -0700, Mandeep Singh Baines wrote:
I think its a good thing pktgen caught this; i am unsure however if it
is doing the right thing. Hoping Robert would respond.
One thing pktgen could do is restrict the amount of outstanding buffers
by using
when you
really need to set this bit.
Anyway, if I rewrite the driver to use TxOK instead of TxIdle, pktgen
works fine.
I think its a good thing pktgen caught this; i am unsure however if it
is doing the right thing. Hoping Robert would respond.
One thing pktgen could do is restrict
From: Robert Olsson [EMAIL PROTECTED]
Date: Mon, 27 Aug 2007 11:16:19 +0200
Initially pkt_dev can be NULL this causes netif_subqueue_stopped to
oops. The patch below should cure it. But maybe the pktgen TX logic
should be reworked to better support the new multiqueue support.
Signed-off
From: Robert Olsson [EMAIL PROTECTED]
Date: Mon, 27 Aug 2007 16:55:19 +0200
Below some pktgen support to send into different TX queues.
This can of course be feed into input queues on other machines
Signed-off-by: Robert Olsson [EMAIL PROTECTED]
Thanks for implementing this Robert, patch
From: Robert Olsson [EMAIL PROTECTED]
Date: Mon, 27 Aug 2007 18:57:19 +0200
Hello, It's not a job for pktgen.
Signed-off-by: Robert Olsson [EMAIL PROTECTED]
Applied, thanks Robert.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED
Hi,
I am having some trouble using pktgen with certain NICs. When running
pktgen on some NICs, the test stalls because the worker thread is
waiting for the driver to free the last skb. If a send a few pings out
the interface, the worker thread will eventually unblock.
Below is the snippet
From: Robert Olsson [EMAIL PROTECTED]
Date: Mon, 27 Aug 2007 20:22:26 +0200
Christoph Hellwig writes:
Hello, It's not a job for pktgen.
Please also kill the do_softirq export while you're at it.
Right seems like pktgen luckily was the only user.
Signed-off-by: Robert Olsson
idle) instead of TX_OK (tx completed) as a way of
coalescing interrupts. I've also seen another driver which does
something similar. Not sure how prevalent this technique is.
So is this a bug in the drivers or a bug in pktgen?
This is a bug since it can stall TCP sockets, and even non-TCP
TX_IDLE (tx
state-machine idle) instead of TX_OK (tx completed) as a way of
coalescing interrupts. I've also seen another driver which does
something similar. Not sure how prevalent this technique is.
So is this a bug in the drivers or a bug in pktgen?
This is a bug since it can stall TCP sockets
From: Rick Jones [EMAIL PROTECTED]
Date: Tue, 28 Aug 2007 16:48:24 -0700
Not to defend any one driver, but could it be that the behaviour of TCP
is such that we've not noticed until now?
Does TCP particularly care for an SKB carrying an ACK? For ones carrying
data there would be an ACK
I don't even understand why this needs to be discussed to be honest
with you :-)
Just my (possibly frustrating :) habit of asking questions which help
further my understanding of the code :)
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message
. In this scenario, the packet has
made it to the wire - just hasnt been freed. Note that when teaching
pktgen to do batching, i removed that logic and things work fine.
cheers,
jamal
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED
to synchronise and make
sure the packet made it to the wire. In this scenario, the packet has
made it to the wire - just hasnt been freed. Note that when teaching
pktgen to do batching, i removed that logic and things work fine.
Hi Jamal,
Here is what the datasheet has to say about TxIdle
, this would be exactly sub-optimal for pktgen or in fact any
application :-)
It seems that the INTbit in the TX descriptor status of the
SIS190 can be an interrupt trigger. In that case, a reasonable
and quite common scheme would be to set that bit every 1/4 of
the TX ring. And also enable
Hello,
Initially pkt_dev can be NULL this causes netif_subqueue_stopped to
oops. The patch below should cure it. But maybe the pktgen TX logic
should be reworked to better support the new multiqueue support.
Cheers
--ro
Signed-off-by: Robert Olsson
Hello,
Below some pktgen support to send into different TX queues.
This can of course be feed into input queues on other machines
Cheers
--ro
Signed-off-by: Robert Olsson [EMAIL PROTECTED]
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index
Hello, It's not a job for pktgen.
Cheers
--ro
Signed-off-by: Robert Olsson [EMAIL PROTECTED]
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 18601af..975e887 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -164,7 +164,7 @@
#include
On Mon, Aug 27, 2007 at 06:57:19PM +0200, Robert Olsson wrote:
Hello, It's not a job for pktgen.
Please also kill the do_softirq export while you're at it.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Christoph Hellwig writes:
Hello, It's not a job for pktgen.
Please also kill the do_softirq export while you're at it.
Right seems like pktgen luckily was the only user.
Cheers
--ro
Signed-off-by: Robert Olsson [EMAIL PROTECTED]
diff --git
On Mon, 2007-07-30 at 16:05 -0700, David Miller wrote:
I still don't know about this patch. Instead of the simple
transformation:
- printk(foo);
+ printk(KERN_INFO foo);
we get this new macro, and the lines changes to use that macro.
Actually, I agree.
Many local macros could
From: Joe Perches [EMAIL PROTECTED]
Date: Tue, 31 Jul 2007 16:48:06 -0700
I'd like to see macros added to kernel.h for:
pr_err
pr_notice
pr_warn
pr_alert
pr_crit
pr_emerge
No objections here :)
-
To unsubscribe from this list: send the line
From: Joe Perches [EMAIL PROTECTED]
Date: Wed, 18 Jul 2007 16:21:00 -0700
On Wed, 2007-07-18 at 15:49 -0700, David Miller wrote:
From: Joe Perches [EMAIL PROTECTED]
Date: Wed, 18 Jul 2007 15:14:13 -0700
-#define VERSION pktgen v2.68: Packet Generator for packet performance
testing
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -162,7 +162,10 @@
#include asm/div64.h /* do_div */
#include asm/timex.h
-#define VERSION pktgen v2.68: Packet Generator for packet performance
testing.\n
+#define PKTGEN_NAMEpktgen
+#define PKTGEN_VERSION v2.68
+#define
From: Joe Perches [EMAIL PROTECTED]
Date: Wed, 18 Jul 2007 15:14:13 -0700
-#define VERSION pktgen v2.68: Packet Generator for packet performance
testing.\n
+#define PKTGEN_NAMEpktgen
+#define PKTGEN_VERSION v2.68
+#define PKTGEN_DESCPacket Generator for packet performance testing
On Wed, 2007-07-18 at 15:49 -0700, David Miller wrote:
From: Joe Perches [EMAIL PROTECTED]
Date: Wed, 18 Jul 2007 15:14:13 -0700
-#define VERSION pktgen v2.68: Packet Generator for packet performance
testing.\n
+#define PKTGEN_NAMEpktgen
+#define PKTGEN_VERSION v2.68
+#define
From: jamal [EMAIL PROTECTED]
Date: Tue, 12 Jun 2007 08:00:28 -0400
commit 38477d7ddfa58f58cce99bc902b4c18883647a71
Author: Jamal Hadi Salim [EMAIL PROTECTED]
Date: Tue Jun 12 06:43:00 2007 -0400
[PKTGEN] Centralize packet overhead tracking
Track the extra packet overhead
SAD lookups.
The only known user at the moment is pktgen.
Signed-off-by: Jamal Hadi Salim [EMAIL PROTECTED]
Applied.
-
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
From: jamal [EMAIL PROTECTED]
Date: Tue, 12 Jun 2007 19:08:39 -0400
commit bfd389bba7654aa118f0949ff0de45a3bce9700c
Author: Jamal Hadi Salim [EMAIL PROTECTED]
Date: Tue Jun 12 18:59:33 2007 -0400
[PKTGEN] IPSEC support
Added transport mode ESP support for starters.
I
This is a set of patches that add ipsec functionality to pktgen.
It is against Daves net-2.6.23
Robert, please take a closer look at this set and either sign off or
comment for me to redo something. I have a short cycle before being
busyed out where i can fix things.
Dave, I would like to push
Manual labor still ... 1 of 4
cheers,
jamal
commit 38477d7ddfa58f58cce99bc902b4c18883647a71
Author: Jamal Hadi Salim [EMAIL PROTECTED]
Date: Tue Jun 12 06:43:00 2007 -0400
[PKTGEN] Centralize packet overhead tracking
Track the extra packet overhead for VLAN tags, MPLS, IPSEC etc
2 of 4
cheers,
jamal
commit 882c296bb3f153e1ac770a874c75cfb2bab8481b
Author: Jamal Hadi Salim [EMAIL PROTECTED]
Date: Tue Jun 12 07:24:00 2007 -0400
[PKTGEN] Introduce sequential flows
By default all flows in pktgen are randomly selected.
This patch introduces ability to have
is pktgen.
Signed-off-by: Jamal Hadi Salim [EMAIL PROTECTED]
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 311f25a..79d2c37 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -920,6 +920,10 @@ extern struct xfrm_state *xfrm_state_find(xfrm_address_t
*daddr
4 of 4
cheers,
jamal
commit e035613eae587251b8c98b7d503eab207f1d26e2
Author: Jamal Hadi Salim [EMAIL PROTECTED]
Date: Tue Jun 12 07:43:30 2007 -0400
[PKTGEN] IPSEC support
Added transport mode ESP support for starters.
I will send more of these modes and types once i have
jamal writes:
3 of 4 ..
[XFRM] Introduce standalone SAD lookup
This allows other in-kernel functions to do SAD lookups.
The only known user at the moment is pktgen.
Signed-off-by: Jamal Hadi Salim [EMAIL PROTECTED]
xfrm is not my area.
Acked-by: Robert
jamal writes:
Manual labor still ... 1 of 4
[PKTGEN] Centralize packet overhead tracking
Track the extra packet overhead for VLAN tags, MPLS, IPSEC etc
Signed-off-by: Jamal Hadi Salim [EMAIL PROTECTED]
Thanks, Jamal.
I'll guess the ipsec part
Looks good too me, just a few minor nitpicks as usual :)
jamal wrote:
[XFRM] Introduce standalone SAD lookup
+struct xfrm_state *
+xfrm_stateonly_find(xfrm_address_t *daddr, xfrm_address_t *saddr,
+ unsigned short family, u8 mode, u8 proto, u32 reqid)
+{
+ unsigned
jamal writes:
4 of 4
[PKTGEN] IPSEC support
Added transport mode ESP support for starters.
I will send more of these modes and types once i have resolved
the tunnel mode isses.
Signed-off-by: Jamal Hadi Salim [EMAIL PROTECTED]
Signed-off-by: Robert
On Tue, 2007-12-06 at 15:21 +0200, Robert Olsson wrote:
I'll guess the ipsec part is to be considered work-in-progress
and you're doing both the work and the progress.
;-
Much thanks Robert.
cheers,
jamal
-
To unsubscribe from this list: send the line unsubscribe netdev
On Tue, 2007-12-06 at 15:45 +0200, Patrick McHardy wrote:
Looks good too me, just a few minor nitpicks as usual :)
I like the nitpicks - they make the code better (as long as we put
a time limit on them ;-)
^^ please delete empty line
will do.
+ if (x-km.state !=
lookups.
The only known user at the moment is pktgen.
Signed-off-by: Jamal Hadi Salim [EMAIL PROTECTED]
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 311f25a..79d2c37 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -920,6 +920,10 @@ extern struct xfrm_state
Sorry Robert, I found a problem compiling when i turned off XFRM. This
fixes it.
cheers,
jamal
commit bfd389bba7654aa118f0949ff0de45a3bce9700c
Author: Jamal Hadi Salim [EMAIL PROTECTED]
Date: Tue Jun 12 18:59:33 2007 -0400
[PKTGEN] IPSEC support
Added transport mode ESP support
This is a set of patches that add ipsec functionality to pktgen. I have
lost these patches before - but they are now fully recovered and well
tested. Robert has glanced at the patches and seems to have no qualms
with them. I am soliciting for any feedback because i would like to push
them
1 of 4.
cheers,
jamal
commit f7da845f37e3cd47be46697491210c126b37c8fc
Author: Jamal Hadi Salim [EMAIL PROTECTED]
Date: Sat Jun 9 09:11:16 2007 -0400
[PKTGEN] Centralize packet overhead tracking
Track the extra packet overhead for VLAN tags, MPLS, IPSEC etc
Signed-off
2 of 4.
cheers,
jamal
commit d0d2c0c2e5539a54d66f07d2fa99bb52c19cc698
Author: Jamal Hadi Salim [EMAIL PROTECTED]
Date: Sat Jun 9 09:12:21 2007 -0400
[PKTGEN] Introduce sequential flows
By default all flows in pktgen are randomly selected.
This patch introduces ability to have
4 of 4
cheers,
jamal
commit d1d8ea490a517df484e6774c4f41123ccde52434
Author: Jamal Hadi Salim [EMAIL PROTECTED]
Date: Sat Jun 9 09:46:52 2007 -0400
[PKTGEN] IPSEC support
Added transport mode ESP support for starters.
I will send more of these modes and types once i have resolved
Josh Triplett wrote:
pktgen currently only works on network devices with type ARPHRD_ETHER. Add
support for the loopback device, type ARPHRD_LOOPBACK.
I've tested this on my system, using a modified pktgen.conf-1-1 with
s/eth1/lo/g, and it works fine; the network device statistics confirm
pktgen currently only works on network devices with type ARPHRD_ETHER. Add
support for the loopback device, type ARPHRD_LOOPBACK.
I've tested this on my system, using a modified pktgen.conf-1-1 with
s/eth1/lo/g, and it works fine; the network device statistics confirm packet
transmission
From: Robert Olsson [EMAIL PROTECTED]
Date: Wed, 28 Feb 2007 18:07:09 +0100
Yes it seems be handle dev name change. So configuration scripts should
use ifindex now :)
Signed-off-by: Robert Olsson [EMAIL PROTECTED]
I will apply all 4 of these patches to net-2.6.22, thanks everyone.
-
To
+++---
1 file changed, 15 insertions(+), 19 deletions(-)
--- pktgen.orig/net/core/pktgen.c2007-02-26 13:21:54.0 -0800
+++ pktgen/net/core/pktgen.c 2007-02-26 13:22:04.0 -0800
@@ -163,9 +163,6 @@
#define VERSION pktgen v2.68: Packet
PROTECTED]
---
net/core/pktgen.c | 52
+++-
1 file changed, 19 insertions(+), 33 deletions(-)
--- pktgen.orig/net/core/pktgen.c2007-02-26 14:34:36.0 -0800
+++ pktgen/net/core/pktgen.c 2007-02-26 14:39:53.0 -0800
PROTECTED]
---
net/core/pktgen.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
--- pktgen.orig/net/core/pktgen.c2007-02-26 14:40:31.0 -0800
+++ pktgen/net/core/pktgen.c 2007-02-26 15:36:38.0 -0800
@@ -167,7 +167,7
(+), 67 deletions(-)
--- pktgen.orig/net/core/pktgen.c2007-02-27 12:08:58.0 -0800
+++ pktgen/net/core/pktgen.c 2007-02-27 12:11:32.0 -0800
@@ -210,15 +210,11 @@
};
struct pktgen_dev {
-
/*
* Try to keep frequent/infrequent used vars. separated
/pktgen.c 2007-02-26 14:40:31.0 -0800
+++ pktgen/net/core/pktgen.c2007-02-26 15:36:38.0 -0800
@@ -167,7 +167,7 @@
#define LAT_BUCKETS_MAX 32
#define IP_NAME_SZ 32
#define MAX_MPLS_LABELS 16 /* This is the max label stack depth */
-#define MPLS_STACK_BOTTOM
:54.0 -0800
+++ pktgen/net/core/pktgen.c2007-02-26 13:22:04.0 -0800
@@ -163,9 +163,6 @@
#define VERSION pktgen v2.68: Packet Generator for packet performance
testing.\n
-/* #define PG_DEBUG(a) a */
-#define PG_DEBUG(a)
-
/* The buckets are exponential in 'width' */
#define
Can use random32() now.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
net/core/pktgen.c | 52 +++-
1 file changed, 19 insertions(+), 33 deletions(-)
--- pktgen.orig/net/core/pktgen.c 2007-02-26 14:34:36.0 -0800
+++ pktgen
+++---
1 file changed, 70 insertions(+), 67 deletions(-)
--- pktgen.orig/net/core/pktgen.c 2007-02-27 12:08:58.0 -0800
+++ pktgen/net/core/pktgen.c2007-02-27 12:11:32.0 -0800
@@ -210,15 +210,11 @@
};
struct pktgen_dev {
-
/*
* Try
startup
and shutdown, but that's it.
Thanks!
commit b3010a665cc33596fbf4be3fc6c3c5c80aeefb65
Author: David S. Miller [EMAIL PROTECTED]
Date: Mon Jan 1 20:51:53 2007 -0800
[PKTGEN]: Convert to kthread API.
Based upon a suggestion from Christoph Hellwig.
This fixes various
the ipg script only works with the old pg3 module and not the new pktgen
module ... attached patch updates the ipg script to support both
-mike
pgpDCI0UbHEoD.pgp
Description: PGP signature
Only load modules if kernel supports modules and try a little bit
harder to locate the pg directory
In article [EMAIL PROTECTED] (at Wed, 20 Dec 2006 10:09:03 -0500), Mike
Frysinger [EMAIL PROTECTED] says:
the ipg script only works with the old pg3 module and not the new pktgen
module ... attached patch updates the ipg script to support both
Applied. Thanks.
--yoshfuji
-
To unsubscribe
+161,7 @@
#include asm/div64.h /* do_div */
#include asm/timex.h
-#define VERSION pktgen v2.68: Packet Generator for packet performance
testing.\n
+#define VERSION pktgen v2.69: Packet Generator for packet performance
testing.\n
/* #define PG_DEBUG(a) a */
#define PG_DEBUG
On Thu, Nov 30, 2006 at 08:14:23PM -0800, David Miller wrote:
Agreed.
Robert, please fix this by using a completion so that we can
wait for the threads to start up, something like this:
No, that's wrong aswell :) Please use the kthread_ API that takes
care of all this. kernel_thread is
@@ -160,7 +161,7 @@
#include asm/div64.h /* do_div */
#include asm/timex.h
-#define VERSION pktgen v2.68: Packet Generator for packet performance
testing.\n
+#define VERSION pktgen v2.69: Packet Generator for packet performance
testing.\n
/* #define PG_DEBUG(a) a */
#define PG_DEBUG
2 of 4 threads got started
but it could be something else...
And the race is hardly seen with any real use of pktgen.. .Let's hear
what others... and completions was out-of-date.
Cheers.
--ro
-
To unsubscribe from this list: send the line unsubscribe
From: Christoph Hellwig [EMAIL PROTECTED]
Date: Fri, 1 Dec 2006 08:22:25 +
On Thu, Nov 30, 2006 at 08:14:23PM -0800, David Miller wrote:
Agreed.
Robert, please fix this by using a completion so that we can
wait for the threads to start up, something like this:
No, that's wrong
of the
pktgen thread execution, it just isn't needed to fix the
bug so we can make it later.
-
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
-#define VERSION pktgen v2.68: Packet Generator for packet performance
testing.\n
+#define VERSION pktgen v2.69: Packet Generator for packet performance
testing.\n
/* #define PG_DEBUG(a) a */
#define PG_DEBUG(a)
@@ -3673,6 +3673,8 @@ static void __exit pg_cleanup(void)
struct
*/
#include asm/timex.h
-#define VERSION pktgen v2.68: Packet Generator for packet performance testing.\n
+#define VERSION pktgen v2.69: Packet Generator for packet performance
testing.\n
/* #define PG_DEBUG(a) a */
#define PG_DEBUG(a)
@@ -3673,6 +3673,8 @@ static void __exit pg_cleanup
*)pktgen_thread_worker, (void *)t,
CLONE_FS | CLONE_FILES | CLONE_SIGHAND);
if (err 0) {
printk(pktgen: kernel_thread() failed for cpu %d\n, t-cpu);
remove_proc_entry(t-name, pg_proc_dir);
list_del(t-th_list
On Tue, Nov 28, 2006 at 03:33:25PM -0800, David Miller wrote:
From: Alexey Dobriyan [EMAIL PROTECTED]
Date: Wed, 22 Nov 2006 00:22:51 +0300
[CCing netdev, bug in pktgen]
[build modular pktgen]
while true; do modprobe pktgen rmmod pktgen; done
BUG: warning at fs/proc
From: Alexey Dobriyan [EMAIL PROTECTED]
Date: Wed, 29 Nov 2006 23:04:37 +0300
Looks like worker thread strategically clears it if scheduled at wrong
moment.
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -3292,7 +3292,6 @@ static void pktgen_thread_worker(struct
On 11/30/06, David Miller [EMAIL PROTECTED] wrote:
From: Alexey Dobriyan [EMAIL PROTECTED]
Date: Wed, 29 Nov 2006 23:04:37 +0300
Looks like worker thread strategically clears it if scheduled at wrong
moment.
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -3292,7 +3292,6 @@ static void
From: Alexey Dobriyan [EMAIL PROTECTED]
Date: Wed, 22 Nov 2006 00:22:51 +0300
[CCing netdev, bug in pktgen]
[build modular pktgen]
while true; do modprobe pktgen rmmod pktgen; done
BUG: warning at fs/proc/generic.c:732/remove_proc_entry()
[c016a7ad
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 matching
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.
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
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
this and sync with
pktgen sending.
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
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...
Just
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
i.e PRE_ROUTE?
I don't think that hook is going to be allowed into the kernel, so the
best I was hoping for was to have the code in pktgen with #if 0 and let
users patch their kernel to add the hook...
Right so what I was trying to say was rather having #if 0 and dead code in
pktgen
of existing hooks already i.e PRE_ROUTE?
For my particular application the hook needs to be right
after the bridge hook. My dev.c hook looks like this:
#if defined(CONFIG_NET_PKTGEN) || defined(CONFIG_NET_PKTGEN_MODULE)
#include pktgen.h
#warning Compiling dev.c for pktgen.;
int
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 various
points, so
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
Changes:
* use a nano-second timer based on the scheduler timer (TSC) for relative
times, instead of get_time_of_day
Ben Greear writes:
I'm planning to re-merge my long-lost pktgen branch with the kernel
tree's pktgen.
I believe the main difference is that my out-of-tree pktgen does not do the
busy-spin, but waits on a queue for the net-device to wake it's tx-queue
when over-driving a NIC
From: Robert Olsson [EMAIL PROTECTED]
Date: Tue, 24 Oct 2006 11:16:05 +0200
My first instinct is to avoid the hook in general code and pktgen let spin
to only affect testing.
Mine too.
Why make everyone in the world make that check in netif_wake_queue(),
or wherever, when %99.999
Robert Olsson wrote:
Ben Greear writes:
I'm planning to re-merge my long-lost pktgen branch with the kernel
tree's pktgen.
I believe the main difference is that my out-of-tree pktgen does not do the
busy-spin, but waits on a queue for the net-device to wake it's tx-queue
when over
David Miller wrote:
From: Robert Olsson [EMAIL PROTECTED]
Date: Tue, 24 Oct 2006 11:16:05 +0200
My first instinct is to avoid the hook in general code and pktgen let spin
to only affect testing.
Mine too.
Why make everyone in the world make that check in netif_wake_queue
201 - 300 of 374 matches
Mail list logo
