On Mon, 18 Sep 2017 11:06:21 +0200
Jesper Dangaard Brouer wrote:
> On Sun, 17 Sep 2017 20:36:36 +0800 Robert Hoo
> wrote:
>
> > Change log
> > v2:
> > Rebased to
> > https://github.com/netoptimizer/network-testing/tree/master/pktgen
>
> Hi Robert,
>
> Thank you for submitting this agains
On Sun, 17 Sep 2017 20:36:36 +0800 Robert Hoo wrote:
> Change log
> v2:
> Rebased to https://github.com/netoptimizer/network-testing/tree/master/pktgen
Hi Robert,
Thank you for submitting this against my git tree[1]. I skimmed the
patches and they looked okay. I'll give them a test run, befor
From: Steve Wise <[EMAIL PROTECTED]>
Date: Mon, 08 Oct 2007 17:46:26 -0500
> We're talking about just for pktgen...eh?
My bad, I'm happy to review a patch that uses the
skb->destructor in pktgen to achieve this.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a
David Miller wrote:
From: Ben Greear <[EMAIL PROTECTED]>
Date: Mon, 08 Oct 2007 14:57:13 -0700
This skb recycling can certainly work and has been done several
times before. It never gets into the kernel though.
Because it doesn't work.
A socket can hang onto a receive packet essentially f
From: Ben Greear <[EMAIL PROTECTED]>
Date: Mon, 08 Oct 2007 14:57:13 -0700
> This skb recycling can certainly work and has been done several
> times before. It never gets into the kernel though.
Because it doesn't work.
A socket can hang onto a receive packet essentially forever.
You cannot th
Steve Wise wrote:
Ben Greear wrote:
Rick Jones wrote:
Perf-wise, you could clone the skbs up front, then deliver them to
the nic in a tight loop. This would mitigate the added overhead
introduced by calling skb_clone() in the loop doing transmits...
That only works if you are sending a sm
Ben Greear wrote:
Rick Jones wrote:
Perf-wise, you could clone the skbs up front, then deliver them to
the nic in a tight loop. This would mitigate the added overhead
introduced by calling skb_clone() in the loop doing transmits...
That only works if you are sending a small number of skbs.
Rick Jones wrote:
Perf-wise, you could clone the skbs up front, then deliver them to
the nic in a tight loop. This would mitigate the added overhead
introduced by calling skb_clone() in the loop doing transmits...
That only works if you are sending a small number of skbs. You can't
pre-clon
Perf-wise, you could clone the skbs up front, then deliver them to the
nic in a tight loop. This would mitigate the added overhead
introduced by calling skb_clone() in the loop doing transmits...
That only works if you are sending a small number of skbs. You can't
pre-clone several minutes w
From: Steve Wise <[EMAIL PROTECTED]>
Date: Mon, 24 Sep 2007 08:54:13 -0500
> I think pktgen should be cloning the skbs using skb_clone(). Then it
> will work for all devices, eh?
The problem is that skb_clone() is (relatively) expensive and
pktgen is trying to just grab a reference to the SKB i
Hi,
Steve Wise writes:
> I think pktgen should be cloning the skbs using skb_clone(). Then it
> will work for all devices, eh?
pktgen assumes for "fastpath" sending exclusive ownership of
the skb. And does a skb_get to avoid final skb destruction so
the same skb can be sent over and over
Steve Wise wrote:
Ben Greear wrote:
Steve Wise wrote:
I think pktgen should be cloning the skbs using skb_clone(). Then
it will work for all devices, eh?
That might work, but it would decrease performance slightly (or,
increase CPU load at least).
Perf-wise, you could clone the skbs up fro
Ben Greear wrote:
Steve Wise wrote:
I think pktgen should be cloning the skbs using skb_clone(). Then it
will work for all devices, eh?
That might work, but it would decrease performance slightly (or,
increase CPU load at least).
Perf-wise, you could clone the skbs up front, then deliver th
Steve Wise wrote:
I think pktgen should be cloning the skbs using skb_clone(). Then it
will work for all devices, eh?
That might work, but it would decrease performance slightly (or,
increase CPU load at least).
Maybe a new option: multi_clone
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela
I think pktgen should be cloning the skbs using skb_clone(). Then it
will work for all devices, eh?
Ben Greear wrote:
jamal wrote:
On Sun, 2007-23-09 at 12:55 -0500, Steve Wise wrote:
Its a hack that breaks cxgb3 because cxgb3 uses the skb->cb area for
each skb passed down. So cxgb3 is
jamal wrote:
On Sun, 2007-23-09 at 12:55 -0500, Steve Wise wrote:
Its a hack that breaks cxgb3 because cxgb3 uses the skb->cb area for
each skb passed down. So cxgb3 is at fault then? IE a driver cannot
use the skb->cb field if the users count is > 1? Or maybe a driver can
_never_ use t
On Sun, 2007-23-09 at 12:55 -0500, Steve Wise wrote:
> Its a hack that breaks cxgb3 because cxgb3 uses the skb->cb area for
> each skb passed down. So cxgb3 is at fault then? IE a driver cannot
> use the skb->cb field if the users count is > 1? Or maybe a driver can
> _never_ use the cb fiel
Hi Steve.
On Sun, Sep 23, 2007 at 11:12:12AM -0500, Steve Wise ([EMAIL PROTECTED]) wrote:
> The pktgen module provides a way to "clone" the skb its using for
> transmission, and allows passing N clones of the originally created skb
> to the driver under test.However, it doesn't really use sk
Evgeniy Polyakov wrote:
Hi Steve.
On Sun, Sep 23, 2007 at 11:12:12AM -0500, Steve Wise ([EMAIL PROTECTED]) wrote:
The pktgen module provides a way to "clone" the skb its using for
transmission, and allows passing N clones of the originally created skb
to the driver under test.However, it
On Wed, 2007-05-09 at 22:06 -0700, Mandeep Singh Baines wrote:
> jamal ([EMAIL PROTECTED]) wrote:
> > If you read the paper: There are no issues with high throughput - NAPI
> > kicks in.
> > The challenge to be overcome is at low traffic, if you have a real fast
> > processor your cpu-cycles-used/
jamal ([EMAIL PROTECTED]) wrote:
> On Wed, 2007-05-09 at 14:55 +0100, James Chapman wrote:
>
> > Thanks Jamal. Yes, I'd already read your paper. I think my idea is
> > different to the ideas described in your paper
>
> I am hoping you can pick from the lessons of what has been tried and
> faile
On Wed, 2007-05-09 at 14:55 +0100, James Chapman wrote:
> Thanks Jamal. Yes, I'd already read your paper. I think my idea is
> different to the ideas described in your paper
I am hoping you can pick from the lessons of what has been tried and
failed and the justification for critiqueing somethi
jamal wrote:
On Wed, 2007-05-09 at 13:03 +0100, James Chapman wrote:
I have a patch that solves the high interrupt rate problem by keeping
the driver in polled mode longer. It's written for the latest NAPI
version that DaveM posted recently. I'll try to get some time to write
it up and post i
On Wed, 2007-05-09 at 13:03 +0100, James Chapman wrote:
> I have a patch that solves the high interrupt rate problem by keeping
> the driver in polled mode longer. It's written for the latest NAPI
> version that DaveM posted recently. I'll try to get some time to write
> it up and post it for c
Mandeep Singh Baines wrote:
Daniele Venzano ([EMAIL PROTECTED]) wrote:
The patch looks good and I think it can be pushed higher (-mm ?) for some wider
testing. I don't have the hardware available to do some tests myself,
unfortunately, but it would be similar to yours anyway.
I'd like to know
Daniele Venzano ([EMAIL PROTECTED]) wrote:
> The patch looks good and I think it can be pushed higher (-mm ?) for some
> wider
> testing. I don't have the hardware available to do some tests myself,
> unfortunately, but it would be similar to yours anyway.
>
> I'd like to know how this works fo
> 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. Plea
On 9/4/07, jamal <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-03-09 at 20:20 -0700, Mandeep Singh Baines wrote:
>
> > I didn't see much saving in interrupts on my machine (too fast, I guess).
>
> You could try the idea suggested by Dave earlier and just turn interupts
> for every nth packet. That shou
- 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 ta
On Mon, 2007-03-09 at 20:20 -0700, Mandeep Singh Baines wrote:
> I didn't see much saving in interrupts on my machine (too fast, I guess).
You could try the idea suggested by Dave earlier and just turn interupts
for every nth packet. That should cut down the numbers.
> I did see a significant b
e by optimizing 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
- 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 down socket apps sendi
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; it
- 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 spewing ;-> My
> thinkin
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
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
On 8/29/07, jamal <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-28-08 at 21:43 -0700, Mandeep Singh Baines wrote:
>
> > I interpret this to mean that the interrupt gets generates after a packet
> > is transferred to the TFIFO on the NIC and the next packet in the ring is
> > NULL.
>
> iow, when tx tran
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 usin
On 8/29/07, Mandeep Baines <[EMAIL PROTECTED]> wrote:
...
> Unfortunately, the TxIdle interrupt would not free the last odd packet.
> However, if we want to quiet interrupts couldn't the driver just be
> converted NAPI. If this seems reasonable I could work on a patch.
It seems reasonable and that
On Tue, 2007-28-08 at 21:43 -0700, Mandeep Singh Baines wrote:
> I interpret this to mean that the interrupt gets generates after a packet
> is transferred to the TFIFO on the NIC and the next packet in the ring is
> NULL.
iow, when tx transits to idle ..
> This interrupt gets generates less of
From: Mandeep Singh Baines <[EMAIL PROTECTED]>
Date: Tue, 28 Aug 2007 21:43:52 -0700
> Here is what the datasheet has to say about TxIdle:
>
> "This event is signaled when the transmit state machine enters the idle state
> from a non-idle state. This will happen whenever the state machine encoun
On Tue, 2007-28-08 at 20:28 -0400, jamal wrote:
> On Tue, 2007-28-08 at 17:06 -0700, David Miller wrote:
>
> > Devices need to free packets in a deterministic amount of time, no
> > matter what.
>
> If i understood the driver pointed to - "finite amount of time" spec is
> still met. Seems some inte
On Tue, 2007-28-08 at 17:06 -0700, David Miller wrote:
> Devices need to free packets in a deterministic amount of time, no
> matter what.
If i understood the driver pointed to - "finite amount of time" spec is
still met. Seems some interupt is generated (TX_IDLE) when the tx path
gets idle and t
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
David Miller wrote:
From: Mandeep Singh Baines <[EMAIL PROTECTED]>
Date: Tue, 28 Aug 2007 15:47:18 -0700
It seems that some drivers do not immediately free skbs on transmit
complete. They will hold the skb until there are more packets to
free. One example is the sis900 driver which uses TX_ID
From: Mandeep Singh Baines <[EMAIL PROTECTED]>
Date: Tue, 28 Aug 2007 15:47:18 -0700
> It seems that some drivers do not immediately free skbs on transmit
> complete. They will hold the skb until there are more packets to
> free. One example is the sis900 driver which uses TX_IDLE (tx
> state-mac
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, p
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.
>
> Signe
From: Robert Olsson <[EMAIL PROTECTED]>
Date: Fri, 1 Dec 2006 09:14:01 +0100
>
> David Miller writes:
>
> > Agreed.
> >
> > Robert, please fix this by using a completion so that we can
> > wait for the threads to start up, something like this:
>
> Included. It passes my test but Alexey and
From: "Alexey Dobriyan" <[EMAIL PROTECTED]>
Date: Fri, 1 Dec 2006 12:51:53 +0300
> On 12/1/06, Robert Olsson <[EMAIL PROTECTED]> wrote:
> > David Miller writes:
> > > Agreed.
> > >
> > > Robert, please fix this by using a completion so that we can
> > > wait for the threads to start up, someth
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
Alexey Dobriyan writes:
>
> Confused now. Is my "t->control &= ~(T_TERMINATE);" fix deprecated by
> completions?
It's not needed with completion patch as this does the job a bit more
mainstream. The T_TERMINATE seems to work well I've tested on machine
with CPU:s. Only once I noticed tha
On 12/1/06, Robert Olsson <[EMAIL PROTECTED]> wrote:
David Miller writes:
> Agreed.
>
> Robert, please fix this by using a completion so that we can
> wait for the threads to start up, something like this:
Included. It passes my test but Alexey and others test.
Confused now. Is my "t->cont
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
David Miller writes:
> Agreed.
>
> Robert, please fix this by using a completion so that we can
> wait for the threads to start up, something like this:
Included. It passes my test but Alexey and others test.
Cheers.
--ro
diff --git a/net/core/pktgen.c b/net
From: Ben Greear <[EMAIL PROTECTED]>
Date: Thu, 30 Nov 2006 09:33:43 -0800
> Robert Olsson wrote:
> > @@ -3673,6 +3673,8 @@ static void __exit pg_cleanup(void)
> > struct list_head *q, *n;
> > wait_queue_head_t queue;
> > init_waitqueue_head(&queue);
> > +
> > + schedule_timeout_i
Robert Olsson wrote:
Hello!
Seems you found a race when rmmod is done before it's fully started
Try:
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 733d86d..ac0b4b1 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -160,7 +160,7 @@
#include/* do_div */
#include
Hello!
Seems you found a race when rmmod is done before it's fully started
Try:
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 733d86d..ac0b4b1 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -160,7 +160,7 @@
#include /* do_div */
#include
-#define VERSION "p
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 && rmmod pktgen; done
> >
> > BUG: w
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()
>[] remove_pro
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
On Mon, 13 Mar 2006, Luiz Fernando Capitulino wrote:
BTW Robert, my TODO list for pktgen so far is:
* A new command called 'rem_device' to remove one device at a time
(currently, we can only remove all devices in one shoot with
'rem_devices_all')
This should be very simple to i
On Mon, 13 Mar 2006 14:29:17 +0100
Robert Olsson <[EMAIL PROTECTED]> wrote:
|
| Luiz Fernando Capitulino writes:
|
| > Well, I wouldn't say it's _really_ needed. But it really avoids having
| > too many thread entries in the pktgen's /proc directory, and as a good
| > result, you will not ha
Luiz Fernando Capitulino writes:
> Well, I wouldn't say it's _really_ needed. But it really avoids having
> too many thread entries in the pktgen's /proc directory, and as a good
> result, you will not have pending threads which will never run as well.
>
> Also note that the patch is triv
Hi Robert,
On Mon, 13 Mar 2006 10:44:49 +0100
Robert Olsson <[EMAIL PROTECTED]> wrote:
|
| Hello!
|
| Really needed?
Well, I wouldn't say it's _really_ needed. But it really avoids having
too many thread entries in the pktgen's /proc directory, and as a good
result, you will not have pendi
From: Luiz Fernando Capitulino <[EMAIL PROTECTED]>
Date: Wed, 1 Mar 2006 23:05:54 -0300
>
> Due to the thread's lock changes, we're at a new version now.
>
> Signed-off-by: Luiz Capitulino <[EMAIL PROTECTED]>
Applied, thanks a lot.
-
To unsubscribe from this list: send the line "unsubscribe ne
From: Luiz Fernando Capitulino <[EMAIL PROTECTED]>
Date: Wed, 1 Mar 2006 23:05:48 -0300
>
> As suggested by Arnaldo, this patch replaces the
> thread_lock()/thread_unlock()
> by directly calls to mutex_lock()/mutex_unlock().
>
> This change makes the code a bit more readable, and the direct c
From: Luiz Fernando Capitulino <[EMAIL PROTECTED]>
Date: Wed, 1 Mar 2006 23:05:43 -0300
>
> pktgen's thread semaphores are strict mutexes, convert them to the mutex
> implementation.
>
> Signed-off-by: Luiz Capitulino <[EMAIL PROTECTED]>
Applied.
-
To unsubscribe from this list: send the line
On 2/22/06, Simon Kirby <[EMAIL PROTECTED]> wrote:
> Of course, now it doesn't send as fast. Hrmph. :) On this older Xeon
> 2.4 Ghz w/533 FSB and e1000 & tg3 @ PCI-X 133 Mhz 64 bit, SMP kernel,
> single pktgen thread, I'm only seeing:
>
> clone_skb=0, 802.1Q tagging, 60 byte:
> e1000: 558526pps 2
On Wed, Feb 22, 2006 at 10:56:31AM -0800, Ben Greear wrote:
> For VLANs, make sure that the 'multi-skb' is always zero. This is because
> the VLAN code modifies the skb by re-assigning the skb->dev to the
> underlying
> device.
>
> I'm not sure if this is the problem you hit, but it could be...
Robert Olsson wrote:
Simon Kirby writes:
> Just tried to do some benchmarks for outgoing packet rates with the
> e1000 and tg3. When I tried some vlan tagging with pktgen, it blew
> up immediately:
Hello!
No pktgen has no support vlan as-is .Guess there should be some config
option to
Simon Kirby wrote:
2.6.15.4:
Just tried to do some benchmarks for outgoing packet rates with the
e1000 and tg3. When I tried some vlan tagging with pktgen, it blew
up immediately:
For VLANs, make sure that the 'multi-skb' is always zero. This is because
the VLAN code modifies the skb by re-a
87 matches
Mail list logo
