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 PR
- 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 l
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 do
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 op
- 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 in
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
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 pktge
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 http://vger.kernel.org/maj
ld it not be sufficient to turn it on once at
> open()?
>
You have to set this bit to restart the Tx State Machine. You could
optimize this if you use the TxIdle interrupt to tell you when you
really need to set this bit.
> > Anyway, if I rewrite the driver to use TxOK instead of TxIdle
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 b
ble interrupts and switch back to interrupt mode of operation.
I just don't know if netperf TCP_RR perf numbers will suffer
(assuming TCP_RR is more important than CPU utilization/efficiency
on heavy TX loads like pktgen.)
grant
-
To unsubscribe from this list: send the line "unsubscribe
for tx complete; which makes me wonder:
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
it doesn't interrupt until the entire TX
ring is empty and has been sent onto the wire.
Yes, 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 reason
n that piece of code
> once - and iirc you said its because you had 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 thi
cket 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.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
th
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
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 A
h uses 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
DLE (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
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 li
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 of
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"
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
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 mul
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 <
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 [EM
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
@@ -1
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
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
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 "
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 c
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
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_N
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_NAME"pktgen"
> +#define PKTGEN_VERSION "v2.68"
> +
100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -162,7 +162,10 @@
#include /* do_div */
#include
-#define VERSION "pktgen v2.68: Packet Generator for packet performance
testing.\n"
+#define PKTGEN_NAME"pktgen"
+#define PKTGEN_VERSION "v2.68&q
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
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]>
Applied.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a me
From: jamal <[EMAIL PROTECTED]>
Date: Tue, 12 Jun 2007 08:01:55 -0400
> commit 882c296bb3f153e1ac770a874c75cfb2bab8481b
> Author: Jamal Hadi Salim <[EMAIL PROTECTED]>
> Date: Tue Jun 12 07:24:00 2007 -0400
>
> [PKTGEN] Introduce sequential flows
>
>
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
&
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 suppo
do SAD 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 struc
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 !=
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 ne
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 PROT
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)
> +{
> + uns
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'
jamal writes:
> 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 d
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
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
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 *xfrm_state_find(xfrm_addre
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 abil
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, IPS
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
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 re
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 abil
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-
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 for
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 co
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
transmissio
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.
-
+---
> 1 file changed, 70 insertions(+), 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 @@
> };
>
&g
Stephen Hemminger <[EMAIL 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 200
ephen Hemminger <[EMAIL 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
>
> ---
> net/core/pktgen.c | 34 +++---
> 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
> @@ -1
en.c | 137 +++---
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 {
-
/*
13:21: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 &#x
-0800
+++ pktgen/net/core/pktgen.c2007-02-26 14:39:53.0 -0800
@@ -464,17 +464,6 @@
return tmp;
}
-static inline u32 pktgen_random(void)
-{
-#if 0
- __u32 n;
- get_random_bytes(&n, 4);
- return n;
-#else
- return net_random();
-#endif
-}
-
static in
ig/net/core/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_
give this a spin? I've tested that the
module loads and unloads properly, the threads 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]
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 bo
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
e bug completely.
But later on we should integate a change that eliminates
these spurious t->control bit clears at the start 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
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, tha
ine
with CPU:s. Only once I noticed that only 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
used now. Is my "t->control &= ~(T_TERMINATE);" fix deprecated by
completions?
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -147,6 +147,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -160,7 +161,7 @@
#include/* do_div */
#includ
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
e/pktgen.c b/net/core/pktgen.c
index 733d86d..a630a73 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -147,6 +147,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -160,7 +161,7 @@
#include /* do_div */
#include
-#define VERSION "pkt
nit_completion(&started);
info.t = t;
info.c = &started;
err = kernel_thread((void *)pktgen_thread_worker, (void *)t,
CLONE_FS | CLONE_FILES | CLONE_SIGHAND);
if (err < 0) {
printk("pktgen: kernel_thread() failed for cp
clude
-#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 vo
RSION "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)
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 @@ st
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
>
> init
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
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
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
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
c
est place to control 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
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
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 wh
e plenty 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 "Compilin
oks already 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
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 resea
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 an
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
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 variou
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_o
From: Ben Greear <[EMAIL PROTECTED]>
Date: Tue, 24 Oct 2006 09:34:38 -0700
> It could be a compile-time option, and even if compiled in, it should
> only be an if branch on
> a pointer. Is there any noticeable performance hit for an if check if
> you wrap it with unlikely?
It's "just an if te
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
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 w
301 - 400 of 492 matches
Mail list logo
