* pktgen: tricks
@ 2009-09-23 5:49 Stephen Hemminger
2009-09-24 0:41 ` Stephen Hemminger
0 siblings, 1 reply; 11+ messages in thread
From: Stephen Hemminger @ 2009-09-23 5:49 UTC (permalink / raw)
To: Jesper Dangaard Brouer, Robert Olsson; +Cc: netdev
I thought others want to know how to get maximum speed of pktgen.
1. Run nothing else (even X11), just a command line
2. Make sure ethernet flow control is disabled
ethtool -A eth0 autoneg off rx off tx off
3. Make sure clocksource is TSC. On my old SMP Opteron's
needed to get patch since in 2.6.30 or later, the clock guru's
decided to remove it on all non Intel machines. Look for patch
than enables "tsc=reliable"
4. Compile Ethernet drivers in, the overhead of the indirect
function call required for modules (or cache footprint),
slows things down.
5. Increase transmit ring size to 1000
ethtool -G eth0 tx 1000
Result: OK: 70408581(c70405979+d2602) nsec, 100000000 (60byte,0frags)
1420281pps 681Mb/sec (681734880bps) errors: 0
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: pktgen: tricks
2009-09-23 5:49 pktgen: tricks Stephen Hemminger
@ 2009-09-24 0:41 ` Stephen Hemminger
2009-09-24 1:05 ` Rick Jones
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Stephen Hemminger @ 2009-09-24 0:41 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jesper Dangaard Brouer, Robert Olsson, netdev
On Tue, 22 Sep 2009 22:49:02 -0700
Stephen Hemminger <shemminger@vyatta.com> wrote:
> I thought others want to know how to get maximum speed of pktgen.
>
> 1. Run nothing else (even X11), just a command line
> 2. Make sure ethernet flow control is disabled
> ethtool -A eth0 autoneg off rx off tx off
> 3. Make sure clocksource is TSC. On my old SMP Opteron's
> needed to get patch since in 2.6.30 or later, the clock guru's
> decided to remove it on all non Intel machines. Look for patch
> than enables "tsc=reliable"
> 4. Compile Ethernet drivers in, the overhead of the indirect
> function call required for modules (or cache footprint),
> slows things down.
> 5. Increase transmit ring size to 1000
> ethtool -G eth0 tx 1000
>
> Result: OK: 70408581(c70405979+d2602) nsec, 100000000 (60byte,0frags)
> 1420281pps 681Mb/sec (681734880bps) errors: 0
Other kernel config help:
- turn off lock dependency checker, kmecheck, page alloc debug
basically anything that slows stuff down
- turn off content group scheduler
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: pktgen: tricks
2009-09-24 0:41 ` Stephen Hemminger
@ 2009-09-24 1:05 ` Rick Jones
2009-09-24 10:10 ` Denys Fedoryschenko
2009-09-30 23:03 ` [PATCH] pktgen: Avoid dirtying skb->users when txq is full Eric Dumazet
2 siblings, 0 replies; 11+ messages in thread
From: Rick Jones @ 2009-09-24 1:05 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jesper Dangaard Brouer, Robert Olsson, netdev
Stephen Hemminger wrote:
> On Tue, 22 Sep 2009 22:49:02 -0700
> Stephen Hemminger <shemminger@vyatta.com> wrote:
>
>
>>I thought others want to know how to get maximum speed of pktgen.
>>
>>1. Run nothing else (even X11), just a command line
>>2. Make sure ethernet flow control is disabled
>> ethtool -A eth0 autoneg off rx off tx off
>>3. Make sure clocksource is TSC. On my old SMP Opteron's
>> needed to get patch since in 2.6.30 or later, the clock guru's
>> decided to remove it on all non Intel machines. Look for patch
>> than enables "tsc=reliable"
>>4. Compile Ethernet drivers in, the overhead of the indirect
>> function call required for modules (or cache footprint),
>> slows things down.
>>5. Increase transmit ring size to 1000
>> ethtool -G eth0 tx 1000
>>
>>Result: OK: 70408581(c70405979+d2602) nsec, 100000000 (60byte,0frags)
>> 1420281pps 681Mb/sec (681734880bps) errors: 0
>
>
> Other kernel config help:
> - turn off lock dependency checker, kmecheck, page alloc debug
> basically anything that slows stuff down
> - turn off content group scheduler
I and thought netperf was getting away from real-world?-)
rick jones
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: pktgen: tricks
2009-09-24 0:41 ` Stephen Hemminger
2009-09-24 1:05 ` Rick Jones
@ 2009-09-24 10:10 ` Denys Fedoryschenko
2009-09-24 10:32 ` Eric Dumazet
2009-09-30 23:03 ` [PATCH] pktgen: Avoid dirtying skb->users when txq is full Eric Dumazet
2 siblings, 1 reply; 11+ messages in thread
From: Denys Fedoryschenko @ 2009-09-24 10:10 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jesper Dangaard Brouer, Robert Olsson, netdev
On Thursday 24 September 2009 03:41:41 Stephen Hemminger wrote:
> Other kernel config help:
> - turn off lock dependency checker, kmecheck, page alloc debug
> basically anything that slows stuff down
> - turn off content group scheduler
Maybe, but i'm not sure (i can't test it):
Disable randomize VA space? On embedded boards it was helping.
In some case disabling SMP helped, when various SMP locks involved, but maybe
not for pktgen.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: pktgen: tricks
2009-09-24 10:10 ` Denys Fedoryschenko
@ 2009-09-24 10:32 ` Eric Dumazet
0 siblings, 0 replies; 11+ messages in thread
From: Eric Dumazet @ 2009-09-24 10:32 UTC (permalink / raw)
To: Denys Fedoryschenko
Cc: Stephen Hemminger, Jesper Dangaard Brouer, Robert Olsson, netdev
Denys Fedoryschenko a écrit :
> On Thursday 24 September 2009 03:41:41 Stephen Hemminger wrote:
>> Other kernel config help:
>> - turn off lock dependency checker, kmecheck, page alloc debug
>> basically anything that slows stuff down
>> - turn off content group scheduler
> Maybe, but i'm not sure (i can't test it):
> Disable randomize VA space? On embedded boards it was helping.
> In some case disabling SMP helped, when various SMP locks involved, but maybe
> not for pktgen.
>
>
pktgen is a kernel module, and is not affected by randomize VA space.
But of course, disabling SMP must help, as long as your machine needs
one cpu only :)
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH] pktgen: Avoid dirtying skb->users when txq is full
2009-09-24 0:41 ` Stephen Hemminger
2009-09-24 1:05 ` Rick Jones
2009-09-24 10:10 ` Denys Fedoryschenko
@ 2009-09-30 23:03 ` Eric Dumazet
2009-10-01 0:25 ` Stephen Hemminger
2 siblings, 1 reply; 11+ messages in thread
From: Eric Dumazet @ 2009-09-30 23:03 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Jesper Dangaard Brouer, Robert Olsson, netdev, David S. Miller
Stephen Hemminger a écrit :
> On Tue, 22 Sep 2009 22:49:02 -0700
> Stephen Hemminger <shemminger@vyatta.com> wrote:
>
>> I thought others want to know how to get maximum speed of pktgen.
>>
>> 1. Run nothing else (even X11), just a command line
>> 2. Make sure ethernet flow control is disabled
>> ethtool -A eth0 autoneg off rx off tx off
>> 3. Make sure clocksource is TSC. On my old SMP Opteron's
>> needed to get patch since in 2.6.30 or later, the clock guru's
>> decided to remove it on all non Intel machines. Look for patch
>> than enables "tsc=reliable"
>> 4. Compile Ethernet drivers in, the overhead of the indirect
>> function call required for modules (or cache footprint),
>> slows things down.
>> 5. Increase transmit ring size to 1000
>> ethtool -G eth0 tx 1000
>>
Thanks a lot Stephen.
I did some pktgen session tonight and found one contention on skb->users field
that following patch avoids.
Before patch :
------------------------------------------------------------------------------
PerfTop: 5187 irqs/sec kernel:100.0% [100000 cycles], (all, cpu: 0)
------------------------------------------------------------------------------
samples pcnt kernel function
_______ _____ _______________
16688.00 - 50.9% : consume_skb
6541.00 - 20.0% : skb_dma_unmap
3277.00 - 10.0% : tg3_poll
1968.00 - 6.0% : mwait_idle
651.00 - 2.0% : irq_entries_start
466.00 - 1.4% : _spin_lock
442.00 - 1.3% : mix_pool_bytes_extract
373.00 - 1.1% : tg3_msi
353.00 - 1.1% : read_tsc
177.00 - 0.5% : sched_clock_local
176.00 - 0.5% : sched_clock
137.00 - 0.4% : tick_nohz_stop_sched_tick
After patch:
------------------------------------------------------------------------------
PerfTop: 3530 irqs/sec kernel:99.9% [100000 cycles], (all, cpu: 0)
------------------------------------------------------------------------------
samples pcnt kernel function
_______ _____ _______________
17127.00 - 34.0% : tg3_poll
12691.00 - 25.2% : consume_skb
5299.00 - 10.5% : skb_dma_unmap
4179.00 - 8.3% : mwait_idle
1583.00 - 3.1% : irq_entries_start
1288.00 - 2.6% : mix_pool_bytes_extract
1239.00 - 2.5% : tg3_msi
1062.00 - 2.1% : read_tsc
583.00 - 1.2% : _spin_lock
432.00 - 0.9% : sched_clock
416.00 - 0.8% : sched_clock_local
360.00 - 0.7% : tick_nohz_stop_sched_tick
329.00 - 0.7% : ktime_get
263.00 - 0.5% : _spin_lock_irqsave
I believe we could go further, batching the atomic_inc(&skb->users) we do all the
time, competing with the atomic_dec() done by tx completion handler (possibly run
on other cpu): Reserve XXXXXXX units to the skb->users, and decrement a pktgen
local variable and refill the reserve if necessary, once in a while...
[PATCH] pktgen: Avoid dirtying skb->users when txq is full
We can avoid two atomic ops on skb->users if packet is not going to be
sent to the device (because hardware txqueue is full)
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 4d11c28..6a9ab28 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -3439,12 +3439,14 @@ static void pktgen_xmit(struct pktgen_dev *pkt_dev)
txq = netdev_get_tx_queue(odev, queue_map);
__netif_tx_lock_bh(txq);
- atomic_inc(&(pkt_dev->skb->users));
- if (unlikely(netif_tx_queue_stopped(txq) || netif_tx_queue_frozen(txq)))
+ if (unlikely(netif_tx_queue_stopped(txq) || netif_tx_queue_frozen(txq))) {
ret = NETDEV_TX_BUSY;
- else
- ret = (*xmit)(pkt_dev->skb, odev);
+ pkt_dev->last_ok = 0;
+ goto unlock;
+ }
+ atomic_inc(&(pkt_dev->skb->users));
+ ret = (*xmit)(pkt_dev->skb, odev);
switch (ret) {
case NETDEV_TX_OK:
@@ -3466,6 +3468,7 @@ static void pktgen_xmit(struct pktgen_dev *pkt_dev)
atomic_dec(&(pkt_dev->skb->users));
pkt_dev->last_ok = 0;
}
+unlock:
__netif_tx_unlock_bh(txq);
/* If pkt_dev->count is zero, then run forever */
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH] pktgen: Avoid dirtying skb->users when txq is full
2009-09-30 23:03 ` [PATCH] pktgen: Avoid dirtying skb->users when txq is full Eric Dumazet
@ 2009-10-01 0:25 ` Stephen Hemminger
2009-10-01 9:47 ` [PATCH] pktgen: Fix delay handling Eric Dumazet
0 siblings, 1 reply; 11+ messages in thread
From: Stephen Hemminger @ 2009-10-01 0:25 UTC (permalink / raw)
To: Eric Dumazet
Cc: Jesper Dangaard Brouer, Robert Olsson, netdev, David S. Miller
On Thu, 01 Oct 2009 01:03:33 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Stephen Hemminger a écrit :
> > On Tue, 22 Sep 2009 22:49:02 -0700
> > Stephen Hemminger <shemminger@vyatta.com> wrote:
> >
> >> I thought others want to know how to get maximum speed of pktgen.
> >>
> >> 1. Run nothing else (even X11), just a command line
> >> 2. Make sure ethernet flow control is disabled
> >> ethtool -A eth0 autoneg off rx off tx off
> >> 3. Make sure clocksource is TSC. On my old SMP Opteron's
> >> needed to get patch since in 2.6.30 or later, the clock guru's
> >> decided to remove it on all non Intel machines. Look for patch
> >> than enables "tsc=reliable"
> >> 4. Compile Ethernet drivers in, the overhead of the indirect
> >> function call required for modules (or cache footprint),
> >> slows things down.
> >> 5. Increase transmit ring size to 1000
> >> ethtool -G eth0 tx 1000
> >>
>
> Thanks a lot Stephen.
>
> I did some pktgen session tonight and found one contention on skb->users field
> that following patch avoids.
>
>
> Before patch :
> ------------------------------------------------------------------------------
> PerfTop: 5187 irqs/sec kernel:100.0% [100000 cycles], (all, cpu: 0)
> ------------------------------------------------------------------------------
>
> samples pcnt kernel function
> _______ _____ _______________
>
> 16688.00 - 50.9% : consume_skb
> 6541.00 - 20.0% : skb_dma_unmap
> 3277.00 - 10.0% : tg3_poll
> 1968.00 - 6.0% : mwait_idle
> 651.00 - 2.0% : irq_entries_start
> 466.00 - 1.4% : _spin_lock
> 442.00 - 1.3% : mix_pool_bytes_extract
> 373.00 - 1.1% : tg3_msi
> 353.00 - 1.1% : read_tsc
> 177.00 - 0.5% : sched_clock_local
> 176.00 - 0.5% : sched_clock
> 137.00 - 0.4% : tick_nohz_stop_sched_tick
>
> After patch:
> ------------------------------------------------------------------------------
> PerfTop: 3530 irqs/sec kernel:99.9% [100000 cycles], (all, cpu: 0)
> ------------------------------------------------------------------------------
>
> samples pcnt kernel function
> _______ _____ _______________
>
> 17127.00 - 34.0% : tg3_poll
> 12691.00 - 25.2% : consume_skb
> 5299.00 - 10.5% : skb_dma_unmap
> 4179.00 - 8.3% : mwait_idle
> 1583.00 - 3.1% : irq_entries_start
> 1288.00 - 2.6% : mix_pool_bytes_extract
> 1239.00 - 2.5% : tg3_msi
> 1062.00 - 2.1% : read_tsc
> 583.00 - 1.2% : _spin_lock
> 432.00 - 0.9% : sched_clock
> 416.00 - 0.8% : sched_clock_local
> 360.00 - 0.7% : tick_nohz_stop_sched_tick
> 329.00 - 0.7% : ktime_get
> 263.00 - 0.5% : _spin_lock_irqsave
>
> I believe we could go further, batching the atomic_inc(&skb->users) we do all the
> time, competing with the atomic_dec() done by tx completion handler (possibly run
> on other cpu): Reserve XXXXXXX units to the skb->users, and decrement a pktgen
> local variable and refill the reserve if necessary, once in a while...
When buffer is allocated we know the number of times it will be cloned. So why
not set it there, would need to cleanup on interrupt but that should be possible.
Alternatively, just change skb->destructor on last packet and use a proper
completion mechanism.
> [PATCH] pktgen: Avoid dirtying skb->users when txq is full
>
> We can avoid two atomic ops on skb->users if packet is not going to be
> sent to the device (because hardware txqueue is full)
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
>
> diff --git a/net/core/pktgen.c b/net/core/pktgen.c
> index 4d11c28..6a9ab28 100644
> --- a/net/core/pktgen.c
> +++ b/net/core/pktgen.c
> @@ -3439,12 +3439,14 @@ static void pktgen_xmit(struct pktgen_dev *pkt_dev)
> txq = netdev_get_tx_queue(odev, queue_map);
>
> __netif_tx_lock_bh(txq);
> - atomic_inc(&(pkt_dev->skb->users));
>
> - if (unlikely(netif_tx_queue_stopped(txq) || netif_tx_queue_frozen(txq)))
> + if (unlikely(netif_tx_queue_stopped(txq) || netif_tx_queue_frozen(txq))) {
> ret = NETDEV_TX_BUSY;
> - else
> - ret = (*xmit)(pkt_dev->skb, odev);
> + pkt_dev->last_ok = 0;
> + goto unlock;
> + }
> + atomic_inc(&(pkt_dev->skb->users));
> + ret = (*xmit)(pkt_dev->skb, odev);
>
> switch (ret) {
> case NETDEV_TX_OK:
> @@ -3466,6 +3468,7 @@ static void pktgen_xmit(struct pktgen_dev *pkt_dev)
> atomic_dec(&(pkt_dev->skb->users));
> pkt_dev->last_ok = 0;
> }
> +unlock:
> __netif_tx_unlock_bh(txq);
>
> /* If pkt_dev->count is zero, then run forever */
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH] pktgen: Fix delay handling
2009-10-01 0:25 ` Stephen Hemminger
@ 2009-10-01 9:47 ` Eric Dumazet
2009-10-01 10:04 ` Eric Dumazet
0 siblings, 1 reply; 11+ messages in thread
From: Eric Dumazet @ 2009-10-01 9:47 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Jesper Dangaard Brouer, Robert Olsson, netdev, David S. Miller
After last pktgen changes, delay handling is wrong.
pktgen actually sends packets at full line speed.
Fix is to update pkt_dev->next_tx even if spin() returns early,
so that next spin() calls have a chance to see a positive delay.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/core/pktgen.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 0bcecbf..1a0682e 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -2106,15 +2106,17 @@ static void pktgen_setup_inject(struct pktgen_dev *pkt_dev)
static void spin(struct pktgen_dev *pkt_dev, ktime_t spin_until)
{
ktime_t start;
- s32 remaining;
+ s64 remaining;
struct hrtimer_sleeper t;
hrtimer_init_on_stack(&t.timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
hrtimer_set_expires(&t.timer, spin_until);
remaining = ktime_to_us(hrtimer_expires_remaining(&t.timer));
- if (remaining <= 0)
+ if (remaining <= 0) {
+ pkt_dev->next_tx = ktime_add_ns(spin_until, pkt_dev->delay);
return;
+ }
start = ktime_now();
if (remaining < 100)
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH] pktgen: Fix delay handling
2009-10-01 9:47 ` [PATCH] pktgen: Fix delay handling Eric Dumazet
@ 2009-10-01 10:04 ` Eric Dumazet
2009-10-01 16:29 ` David Miller
0 siblings, 1 reply; 11+ messages in thread
From: Eric Dumazet @ 2009-10-01 10:04 UTC (permalink / raw)
To: Stephen Hemminger, David S. Miller
Cc: Jesper Dangaard Brouer, Robert Olsson, netdev
Eric Dumazet a écrit :
> After last pktgen changes, delay handling is wrong.
>
> pktgen actually sends packets at full line speed.
>
> Fix is to update pkt_dev->next_tx even if spin() returns early,
> so that next spin() calls have a chance to see a positive delay.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Oh well, I hit this bug on linux-2.6 git tree, but I did the patch on net-next-2.6
But it appears net/core/pktgen.c is different on net-next-2.6
Stephen, David, I am a bit lost here, something went wrong in a merge process ?
In any case, here is the patch against Linus tree, where bug is present.
Thanks
[PATCH] pktgen: Fix delay handling
After last pktgen changes, delay handling is wrong.
pktgen actually sends packets at full line speed.
Fix is to update pkt_dev->next_tx even if spin() returns early,
so that next spin() calls have a chance to see a positive delay.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 4d11c28..b694552 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -2105,15 +2105,17 @@ static void pktgen_setup_inject(struct pktgen_dev *pkt_dev)
static void spin(struct pktgen_dev *pkt_dev, ktime_t spin_until)
{
ktime_t start_time, end_time;
- s32 remaining;
+ s64 remaining;
struct hrtimer_sleeper t;
hrtimer_init_on_stack(&t.timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
hrtimer_set_expires(&t.timer, spin_until);
remaining = ktime_to_us(hrtimer_expires_remaining(&t.timer));
- if (remaining <= 0)
+ if (remaining <= 0) {
+ pkt_dev->next_tx = ktime_add_ns(spin_until, pkt_dev->delay);
return;
+ }
start_time = ktime_now();
if (remaining < 100)
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH] pktgen: Fix delay handling
2009-10-01 10:04 ` Eric Dumazet
@ 2009-10-01 16:29 ` David Miller
2009-10-01 16:32 ` Eric Dumazet
0 siblings, 1 reply; 11+ messages in thread
From: David Miller @ 2009-10-01 16:29 UTC (permalink / raw)
To: eric.dumazet; +Cc: shemminger, jdb, robert, netdev
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 01 Oct 2009 12:04:41 +0200
> But it appears net/core/pktgen.c is different on net-next-2.6
>
> Stephen, David, I am a bit lost here, something went wrong in a merge process ?
>
net-next-2.6 is just a stale old tree, there is no new networking
work in there and it is simply Linus's tree as of a few weeks
ago.
It's only there so Stephen Rothwell has something to do a 'nop'
pull from into his linux-next tree.
I'll apply your fix, thanks!
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] pktgen: Fix delay handling
2009-10-01 16:29 ` David Miller
@ 2009-10-01 16:32 ` Eric Dumazet
0 siblings, 0 replies; 11+ messages in thread
From: Eric Dumazet @ 2009-10-01 16:32 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, jdb, robert, netdev
David Miller a écrit :
> net-next-2.6 is just a stale old tree, there is no new networking
> work in there and it is simply Linus's tree as of a few weeks
> ago.
>
> It's only there so Stephen Rothwell has something to do a 'nop'
> pull from into his linux-next tree.
>
> I'll apply your fix, thanks!
Thanks for the explanation David.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2009-10-01 16:32 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-09-23 5:49 pktgen: tricks Stephen Hemminger
2009-09-24 0:41 ` Stephen Hemminger
2009-09-24 1:05 ` Rick Jones
2009-09-24 10:10 ` Denys Fedoryschenko
2009-09-24 10:32 ` Eric Dumazet
2009-09-30 23:03 ` [PATCH] pktgen: Avoid dirtying skb->users when txq is full Eric Dumazet
2009-10-01 0:25 ` Stephen Hemminger
2009-10-01 9:47 ` [PATCH] pktgen: Fix delay handling Eric Dumazet
2009-10-01 10:04 ` Eric Dumazet
2009-10-01 16:29 ` David Miller
2009-10-01 16:32 ` Eric Dumazet
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.