* Possible 2.6.22 -> 2.6.23 HTB regression?
From: Denys @ 2007-10-10 12:05 UTC (permalink / raw)
To: netdev
Hi 2 all again
I have shaper, running very simple HTB tree (about 10 classes).
Traffic is coming via eth0, and going over eth0.1000, shaper installed on
eth0.1000 (802.1Q vlan), total rate is 85Mbit/s.
On kernel 2.6.22 with bnx2 eth0 everything was working fine.
I have another server with similar task, with e1000, and was shaping rate
lower than expected on 2.6.22. On full load it was 65-66Mbit/s instead 88Mbit/
s. So i postpone troubleshooting, and moved it as backup server.
When i upgrade server with bnx2 to 2.6.23 i got the same behaviour on bnx2
too.
Even with extended burst/cburst it is around 82.5Mbit/s instead 85Mbit/s.
(calculation with 5 second delay)
82319/82354 KBit/S (52684221/52706721) (0/0)
82375/82368 KBit/S (52720558/52716058) (52684221/52706721)
82500/82500 KBit/S (52800425/52800425) (105404779/105422779)
82406/82406 KBit/S (52740119/52740119) (158205204/158223204)
82615/82631 KBit/S (52873964/52884464) (210945323/210963323)
82459/82464 KBit/S (52774379/52777379) (263819287/263847787)
Here is tc -s -d class show dev eth0.2022 when i run without custom burst/
cburst (after 60 seconds)
class htb 1:100 root rate 85000Kbit ceil 85000Kbit burst 1583b/8 mpu 0b
overhead 0b cburst 1583b/8 mpu 0b overhead 0b level 7
Sent 511732440 bytes 348298 pkt (dropped 0, overlimits 0 requeues 0)
rate 67637Kbit 5774pps backlog 0b 0p requeues 0
lended: 4029 borrowed: 0 giants: 0
tokens: -764 ctokens: -764
class htb 1:200 parent 1:100 leaf 200: prio 0 quantum 2000 rate 5000Kbit ceil
85000Kbit burst 1600b/8 mpu 0b overhead 0b cburst 1583b/8 mpu 0b overhead 0b
level 0
Sent 1785787 bytes 8180 pkt (dropped 0, overlimits 0 requeues 0)
rate 312608bit 162pps backlog 0b 0p requeues 0
lended: 8090 borrowed: 90 giants: 0
tokens: 2426 ctokens: 143
class htb 1:923 parent 1:920 leaf 923: prio 0 quantum 2000 rate 5000Kbit ceil
85000Kbit burst 1600b/8 mpu 0b overhead 0b cburst 1583b/8 mpu 0b overhead 0b
level 0
Sent 16491797 bytes 10896 pkt (dropped 0, overlimits 0 requeues 0)
rate 2171Kbit 179pps backlog 0b 0p requeues 0
lended: 10673 borrowed: 223 giants: 0
tokens: 138 ctokens: 8
class htb 1:910 parent 1:900 leaf 910: prio 0 quantum 2000 rate 50000Kbit
ceil 85000Kbit burst 1600b/8 mpu 0b overhead 0b cburst 1583b/8 mpu 0b
overhead 0b level 0
Sent 276577122 bytes 185876 pkt (dropped 7427, overlimits 0 requeues 0)
rate 36497Kbit 3065pps backlog 0b 444p requeues 0
lended: 182521 borrowed: 2911 giants: 0
tokens: -455 ctokens: -117
class htb 1:922 parent 1:920 leaf 922: prio 5 quantum 2000 rate 5000Kbit ceil
85000Kbit burst 1600b/8 mpu 0b overhead 0b cburst 1583b/8 mpu 0b overhead 0b
level 0
Sent 56949991 bytes 37706 pkt (dropped 34663, overlimits 0 requeues 0)
rate 7298Kbit 604pps backlog 0b 823p requeues 0
lended: 24844 borrowed: 12039 giants: 0
tokens: -4641 ctokens: -110
class htb 1:900 parent 1:100 rate 80000Kbit ceil 85000Kbit burst 1590b/8 mpu
0b overhead 0b cburst 1583b/8 mpu 0b overhead 0b level 6
Sent 509946653 bytes 340118 pkt (dropped 0, overlimits 0 requeues 0)
rate 67324Kbit 5612pps backlog 0b 0p requeues 0
lended: 10152 borrowed: 3939 giants: 0
tokens: -850 ctokens: -764
class htb 1:921 parent 1:920 leaf 921: prio 5 quantum 2000 rate 20000Kbit
ceil 85000Kbit burst 1600b/8 mpu 0b overhead 0b cburst 1583b/8 mpu 0b
overhead 0b level 0
Sent 162349726 bytes 107246 pkt (dropped 51305, overlimits 0 requeues 0)
rate 21252Kbit 1755pps backlog 0b 339p requeues 0
lended: 94785 borrowed: 12122 giants: 0
tokens: -1113 ctokens: -239
class htb 1:920 parent 1:900 rate 30000Kbit ceil 85000Kbit burst 1593b/8 mpu
0b overhead 0b cburst 1583b/8 mpu 0b overhead 0b level 5
Sent 234033699 bytes 154686 pkt (dropped 0, overlimits 0 requeues 0)
rate 30719Kbit 2538pps backlog 0b 0p requeues 0
lended: 13204 borrowed: 11180 giants: 0
tokens: -1780 ctokens: -505
Here is tc -s -d class show dev eth0.2022 when i run WITH custom burst/cburst
(after 60 seconds)
class htb 1:100 root rate 85000Kbit ceil 85000Kbit burst 16Kb/8 mpu 0b
overhead 0b cburst 8Kb/8 mpu 0b overhead 0b level 7
Sent 637707898 bytes 430930 pkt (dropped 0, overlimits 0 requeues 0)
rate 83982Kbit 7082pps backlog 0b 0p requeues 0
lended: 22809 borrowed: 0 giants: 0
tokens: -2453 ctokens: -3206
class htb 1:200 parent 1:100 leaf 200: prio 0 quantum 2000 rate 5000Kbit ceil
85000Kbit burst 16Kb/8 mpu 0b overhead 0b cburst 8Kb/8 mpu 0b overhead 0b
level 0
Sent 1266780 bytes 7041 pkt (dropped 0, overlimits 0 requeues 0)
rate 128920bit 102pps backlog 0b 0p requeues 0
lended: 6983 borrowed: 58 giants: 0
tokens: 23250 ctokens: 615
class htb 1:923 parent 1:920 leaf 923: prio 0 quantum 2000 rate 5000Kbit ceil
85000Kbit burst 16Kb/8 mpu 0b overhead 0b cburst 8Kb/8 mpu 0b overhead 0b
level 0
Sent 16484432 bytes 10888 pkt (dropped 0, overlimits 0 requeues 0)
rate 2172Kbit 179pps backlog 0b 0p requeues 0
lended: 10888 borrowed: 0 giants: 0
tokens: 18537 ctokens: 362
class htb 1:910 parent 1:900 leaf 910: prio 0 quantum 2000 rate 50000Kbit
ceil 85000Kbit burst 16Kb/8 mpu 0b overhead 0b cburst 8Kb/8 mpu 0b overhead
0b level 0
Sent 278162766 bytes 187188 pkt (dropped 0, overlimits 0 requeues 0)
rate 34963Kbit 2943pps backlog 0b 19p requeues 0
lended: 182346 borrowed: 4823 giants: 0
tokens: -2472 ctokens: -755
class htb 1:922 parent 1:920 leaf 922: prio 5 quantum 2000 rate 5000Kbit ceil
85000Kbit burst 16Kb/8 mpu 0b overhead 0b cburst 8Kb/8 mpu 0b overhead 0b
level 0
Sent 119217036 bytes 78793 pkt (dropped 23901, overlimits 0 requeues 0)
rate 16355Kbit 1351pps backlog 0b 653p requeues 0
lended: 24715 borrowed: 53425 giants: 0
tokens: -25785 ctokens: -691
class htb 1:900 parent 1:100 rate 80000Kbit ceil 85000Kbit burst 16Kb/8 mpu
0b overhead 0b cburst 8Kb/8 mpu 0b overhead 0b level 6
Sent 636441118 bytes 423889 pkt (dropped 0, overlimits 0 requeues 0)
rate 83853Kbit 6981pps backlog 0b 0p requeues 0
lended: 69858 borrowed: 22751 giants: 0
tokens: -3801 ctokens: -3063
class htb 1:921 parent 1:920 leaf 921: prio 5 quantum 2000 rate 20000Kbit
ceil 85000Kbit burst 16Kb/8 mpu 0b overhead 0b cburst 8Kb/8 mpu 0b overhead
0b level 0
Sent 224022740 bytes 147977 pkt (dropped 36921, overlimits 0 requeues 0)
rate 30486Kbit 2517pps backlog 0b 285p requeues 0
lended: 98381 borrowed: 49311 giants: 0
tokens: -6581 ctokens: -851
class htb 1:920 parent 1:900 rate 30000Kbit ceil 85000Kbit burst 16Kb/8 mpu
0b overhead 0b cburst 8Kb/8 mpu 0b overhead 0b level 5
Sent 358305020 bytes 236720 pkt (dropped 0, overlimits 0 requeues 0)
rate 48861Kbit 4035pps backlog 0b 0p requeues 0
lended: 14950 borrowed: 87786 giants: 0
tokens: -7376 ctokens: -851
Bandwidth stats when i run with custom cburst/burst
81932/81932 KBit/S (52436973/52436973) (7697899990/7698153316)
82465/82463 KBit/S (52778238/52776738) (7750336963/7750590289)
82289/82291 KBit/S (52665172/52666672) (7803115201/7803367027)
Now i run without them
65812/65812 KBit/S (42119718/42119718) (7855780373/7856033699)
65300/65300 KBit/S (41792304/41792304) (7897900091/7898153417)
67133/67133 KBit/S (42965445/42965445) (7939692395/7939945721)
Right now shaper looks like this (burst and cburst added recently,it helps a
bit to increase rate):
#!/bin/sh
DEV=eth0.2022
ROOTRATE=85000Kbit
tc qdisc del dev ${DEV} root
tc qdisc add dev ${DEV} root handle 1: htb default 2000
tc class add dev ${DEV} parent 1: classid 1:100 htb rate ${ROOTRATE} quantum
2000 burst 16k cburst 8k
tc class add dev ${DEV} parent 1:100 classid 1:200 htb rate 5000Kbit ceil
${ROOTRATE} quantum 2000 burst 16k cburst 8k
tc qdisc add dev ${DEV} parent 1:200 handle 200: bfifo limit 5120000
tc filter add dev ${DEV} parent 1:0 prio 1100 protocol ip u32 match ip dst
0.0.0.0/0 classid 1:200
tc class add dev ${DEV} parent 1:100 classid 1:900 htb rate 80000Kbit ceil
${ROOTRATE} quantum 2000 burst 16k cburst 8k
#SUPERCAFE
#Browsing
tc class add dev ${DEV} parent 1:900 classid 1:910 htb rate 50000Kbit ceil
${ROOTRATE} quantum 2000 burst 16k cburst 8k
tc qdisc add dev ${DEV} parent 1:910 handle 910: bfifo limit 2120000
tc filter add dev ${DEV} parent 1:0 prio 100 protocol ip u32 match ip src
217.151.224.29/32 match ip protocol 17 0xff match ip sport 21004 0xffff
classid 1:910
#Downloads
tc class add dev ${DEV} parent 1:900 classid 1:920 htb rate 30000Kbit ceil
${ROOTRATE} quantum 2000 burst 16k cburst 8k
tc class add dev ${DEV} parent 1:920 classid 1:921 htb rate 20000Kbit ceil
${ROOTRATE} quantum 2000 burst 16k cburst 8k prio 5
tc qdisc add dev ${DEV} parent 1:921 handle 921: bfifo limit 520000
tc filter add dev ${DEV} parent 1:0 prio 95 protocol ip u32 match ip src
217.151.224.29/32 match ip protocol 17 0xff match ip sport 21005 0xffff match
ip dst 213.187.247.1/32 classid 1:921
tc filter add dev ${DEV} parent 1:0 prio 95 protocol ip u32 match ip src
217.151.224.29/32 match ip protocol 17 0xff match ip sport 21005 0xffff match
ip dst 213.187.247.2/32 classid 1:921
tc filter add dev ${DEV} parent 1:0 prio 95 protocol ip u32 match ip src
217.151.224.29/32 match ip protocol 17 0xff match ip sport 21005 0xffff match
ip dst 213.187.247.3/32 classid 1:921
tc class add dev ${DEV} parent 1:920 classid 1:922 htb rate 5000Kbit ceil
${ROOTRATE} quantum 2000 burst 16k cburst 8k prio 5
tc qdisc add dev ${DEV} parent 1:922 handle 922: bfifo limit 1250000
tc filter add dev ${DEV} parent 1:0 prio 100 protocol ip u32 match ip src
217.151.224.29/32 match ip protocol 17 0xff match ip sport 21005 0xffff
classid 1:922
tc class add dev ${DEV} parent 1:920 classid 1:923 htb rate 5000Kbit ceil
${ROOTRATE} quantum 2000 burst 16k cburst 8k
tc qdisc add dev ${DEV} parent 1:923 handle 923: bfifo limit 500000
tc filter add dev ${DEV} parent 1:0 prio 20 protocol ip u32 match ip dst
213.187.247.11/32 classid 1:923
--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.
^ permalink raw reply
* Re: [RFC PATCH net-2.6.24 0/5]: TCP sacktag cache usage recoded
From: David Miller @ 2007-10-10 10:45 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: shemminger, sangtae.ha, virtualphtn, baruch, netdev
In-Reply-To: <Pine.LNX.4.64.0710101300221.3767@kivilampi-30.cs.helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Wed, 10 Oct 2007 13:26:05 +0300 (EEST)
> Hmm, SACK code is under such flux currently that I'll
> have to deal conflicts almost daily due to overlapping ideas...
Welcome to my world, just scale it to 800 patches and entire
networking tree :-))))
^ permalink raw reply
* Re: [ofa-general] Re: [PATCH 2/3][NET_BATCH] net core use batching
From: David Miller @ 2007-10-10 10:44 UTC (permalink / raw)
To: andi
Cc: hadi, shemminger, jeff, johnpol, herbert, gaagaan, Robert.Olsson,
netdev, rdreier, peter.p.waskiewicz.jr, mcarlson, jagana, general,
mchan, tgraf, randy.dunlap, sri, kaber
In-Reply-To: <20071010102331.GA10496@one.firstfloor.org>
From: Andi Kleen <andi@firstfloor.org>
Date: Wed, 10 Oct 2007 12:23:31 +0200
> On Wed, Oct 10, 2007 at 02:25:50AM -0700, David Miller wrote:
> > The chip I was working with at the time (UltraSPARC-IIi) compressed
> > all the linear stores into 64-byte full cacheline transactions via
> > the store buffer.
>
> That's a pretty old CPU. Conclusions on more modern ones might be different.
Cache matters, just scale the numbers.
> I suppose it would be an interesting experiment at least.
Absolutely.
I've always gotten very poor results when increasing the TX queue a
lot, for example with NIU the point of diminishing returns seems to
be in the range of 256-512 TX descriptor entries and this was with
1.6Ghz cpus.
^ permalink raw reply
* Re: [RFC PATCH net-2.6.24 0/5]: TCP sacktag cache usage recoded
From: Ilpo Järvinen @ 2007-10-10 10:26 UTC (permalink / raw)
To: David Miller
Cc: Stephen Hemminger, sangtae.ha, virtualphtn, Baruch Even, Netdev
In-Reply-To: <20071010.025829.106434530.davem@davemloft.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1395 bytes --]
On Wed, 10 Oct 2007, David Miller wrote:
> From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
> Date: Mon, 24 Sep 2007 13:28:42 +0300
>
> > After couple of wrong-wayed before/after()s and one infinite
> > loopy version, here's the current trial version of a sacktag
> > cache usage recode....
> >
> > Two first patches come from tcp-2.6 (rebased and rotated).
> > This series apply cleanly only on top of the other three patch
> > series I posted earlier today. The last debug patch provides
> > some statistics for those interested enough.
> >
> > Dave, please DO NOT apply! ...Some thoughts could be nice
> > though :-).
>
> Ilpo, I have not forgotten about this patch set.
>
> It is something I plan to look over after the madness of merging
> net-2.6.24 to Linus is complete.
Thanks, there's probably going to be some trouble though, I'd bet it
doesn't anymore apply cleanly to net-2.6.23 HEAD because of something else
that got applied (don't remember exactly but I guess that highest_sack
reno fix did that).
I try to get them resent soon but currently my thoughts are in solving
DSACK ignored bug (and doing the associated cleanups) which again will
cause those code move conflicts to reoccur. Therefore I'd love to postpone
the rebase a bit... Hmm, SACK code is under such flux currently that I'll
have to deal conflicts almost daily due to overlapping ideas...
--
i.
^ permalink raw reply
* Re: [ofa-general] Re: [PATCH 2/3][NET_BATCH] net core use batching
From: Andi Kleen @ 2007-10-10 10:23 UTC (permalink / raw)
To: David Miller
Cc: andi, hadi, shemminger, jeff, johnpol, herbert, gaagaan,
Robert.Olsson, netdev, rdreier, peter.p.waskiewicz.jr, mcarlson,
jagana, general, mchan, tgraf, randy.dunlap, sri, kaber
In-Reply-To: <20071010.022550.21928751.davem@davemloft.net>
On Wed, Oct 10, 2007 at 02:25:50AM -0700, David Miller wrote:
> The chip I was working with at the time (UltraSPARC-IIi) compressed
> all the linear stores into 64-byte full cacheline transactions via
> the store buffer.
That's a pretty old CPU. Conclusions on more modern ones might be different.
> In fact, such a thing might not pan out well, because most of the time
> you write a single descriptor or two, and that isn't a full cacheline,
> which means a read/modify/write is the only coherent way to make such
> a write to RAM.
x86 WC does R-M-W and is coherent of course. The main difference is
just that the result is not cached. When the hardware accesses the cache line
then the cache should be also invalidated.
> Sure you could batch, but I'd rather give the chip work to do unless
> I unequivocably knew I'd have enough pending to fill a cacheline's
> worth of descriptors. And since you suggest we shouldn't queue in
> software... :-)
Hmm, it probably would need to be coupled with batched submission if
multiple packets are available you're right. Probably not worth doing explicit
queueing though.
I suppose it would be an interesting experiment at least.
-Andi
^ permalink raw reply
* [PATCH] natsemi: Use round_jiffies() for slow timers
From: Mark Brown @ 2007-10-10 10:05 UTC (permalink / raw)
To: Jeff Garzik, thockin; +Cc: netdev, linux-kernel, Mark Brown
In-Reply-To: <470C210C.6030800@pobox.com>
Unless we have failed to fill the RX ring the timer used by the natsemi
driver is not particularly urgent and can use round_jiffies() to allow
grouping with other timers.
Signed-off-by: Mark Brown <broonie@sirena.org.uk>
---
Rediffed against current netdev-2.6.git#upstream
drivers/net/natsemi.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/natsemi.c b/drivers/net/natsemi.c
index 527f9dc..b881786 100644
--- a/drivers/net/natsemi.c
+++ b/drivers/net/natsemi.c
@@ -1576,7 +1576,7 @@ static int netdev_open(struct net_device *dev)
/* Set the timer to check for link beat. */
init_timer(&np->timer);
- np->timer.expires = jiffies + NATSEMI_TIMER_FREQ;
+ np->timer.expires = round_jiffies(jiffies + NATSEMI_TIMER_FREQ);
np->timer.data = (unsigned long)dev;
np->timer.function = &netdev_timer; /* timer handler */
add_timer(&np->timer);
@@ -1856,7 +1856,11 @@ static void netdev_timer(unsigned long data)
next_tick = 1;
}
}
- mod_timer(&np->timer, jiffies + next_tick);
+
+ if (next_tick > 1)
+ mod_timer(&np->timer, round_jiffies(jiffies + next_tick));
+ else
+ mod_timer(&np->timer, jiffies + next_tick);
}
static void dump_ring(struct net_device *dev)
@@ -3331,7 +3335,7 @@ static int natsemi_resume (struct pci_dev *pdev)
spin_unlock_irq(&np->lock);
enable_irq(dev->irq);
- mod_timer(&np->timer, jiffies + 1*HZ);
+ mod_timer(&np->timer, round_jiffies(jiffies + 1*HZ));
}
netif_device_attach(dev);
out:
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH] division-by-zero in inet_csk_get_port
From: David Miller @ 2007-10-10 10:01 UTC (permalink / raw)
To: aarapov; +Cc: netdev, den
In-Reply-To: <m3wstvjnso.fsf@bandura.englab.brq.redhat.com>
From: Anton Arapov <aarapov@redhat.com>
Date: Wed, 10 Oct 2007 11:56:23 +0200
> Yep, that's exactly I'm talking about. I'm sure that
> [...] % (high - low) [...] erroneous from the begining, because
> in such places we want to have 1 in denominator, for the cases when we
> have only one port. Because 34000 34000 in sysctl's
> ip_local_port_range means 1(one) port, not 0(zero).
>
> So it seems to me that we have to fix mentioned denominators in
> kernel/net to have 1, that will be correct logically. And do the
> MAX<MIN check in sysctl code.
> From this point of view, it's best idea to have two patches: one for
> the kernel/net denominators and another one for the sysctl.c's
> function dointvec_minmax(). Because they can live independently. And
> the patch for the kernel/net will do the work at least because we
> prevent kernel trap at all.
>
> Dave, am I right?
Sure, two patches is fine.
^ permalink raw reply
* Re: [RFC PATCH net-2.6.24 0/5]: TCP sacktag cache usage recoded
From: David Miller @ 2007-10-10 9:58 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: shemminger, sangtae.ha, virtualphtn, baruch, netdev
In-Reply-To: <11906297271684-git-send-email-ilpo.jarvinen@helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Mon, 24 Sep 2007 13:28:42 +0300
> After couple of wrong-wayed before/after()s and one infinite
> loopy version, here's the current trial version of a sacktag
> cache usage recode....
>
> Two first patches come from tcp-2.6 (rebased and rotated).
> This series apply cleanly only on top of the other three patch
> series I posted earlier today. The last debug patch provides
> some statistics for those interested enough.
>
> Dave, please DO NOT apply! ...Some thoughts could be nice
> though :-).
Ilpo, I have not forgotten about this patch set.
It is something I plan to look over after the madness of merging
net-2.6.24 to Linus is complete.
^ permalink raw reply
* Re: [PATCH] division-by-zero in inet_csk_get_port
From: Anton Arapov @ 2007-10-10 9:56 UTC (permalink / raw)
To: David Miller; +Cc: netdev, den
In-Reply-To: <20071010.023515.15263796.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1391 bytes --]
David Miller <davem@davemloft.net> writes:
>> Ok, I've got it, so we have to do the same with the following:
>> quote from inet_hashtables.c and inet6_hashtables.c. I'll prepare the
>> patch.
>>
>> And just a curious, does the /* Treat low > high as high == low */
>> idea will keep after the sysctl will be patched?
>
> I'm beginning to think that we should do the sysctl validation
> in this patch too, instead of duplicating this grotty check
> in all of these port selection functions.
Yep, that's exactly I'm talking about. I'm sure that
[...] % (high - low) [...] erroneous from the begining, because
in such places we want to have 1 in denominator, for the cases when we
have only one port. Because 34000 34000 in sysctl's
ip_local_port_range means 1(one) port, not 0(zero).
So it seems to me that we have to fix mentioned denominators in
kernel/net to have 1, that will be correct logically. And do the
MAX<MIN check in sysctl code.
From this point of view, it's best idea to have two patches: one for
the kernel/net denominators and another one for the sysctl.c's
function dointvec_minmax(). Because they can live independently. And
the patch for the kernel/net will do the work at least because we
prevent kernel trap at all.
Dave, am I right?
--
Anton Arapov, <aarapov@redhat.com>
Kernel Development, Red Hat
GPG Key ID: 0x6FA8C812
[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]
^ permalink raw reply
* Re: [ofa-general] Re: [PATCH 2/3][NET_BATCH] net core use batching
From: Herbert Xu @ 2007-10-10 9:53 UTC (permalink / raw)
To: Andi Kleen
Cc: David Miller, hadi, shemminger, jeff, johnpol, gaagaan,
Robert.Olsson, netdev, rdreier, peter.p.waskiewicz.jr, mcarlson,
jagana, general, mchan, tgraf, randy.dunlap, sri, kaber
In-Reply-To: <20071010091644.GA9807@one.firstfloor.org>
On Wed, Oct 10, 2007 at 11:16:44AM +0200, Andi Kleen wrote:
> > A 256 entry TX hw queue fills up trivially on 1GB and 10GB, but if you
>
> With TSO really?
Hardware queues are generally per-page rather than per-skb so
it'd fill up quicker than a software queue even with TSO.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] [IPV6] Defer IPv6 device initialization until a valid qdisc is specified
From: David Miller @ 2007-10-10 9:53 UTC (permalink / raw)
To: mitch; +Cc: netdev, yoshfuji, herbert
In-Reply-To: <20071009162158.f25d4fdb.mitch@linux.vnet.ibm.com>
From: Mitsuru Chinen <mitch@linux.vnet.ibm.com>
Date: Tue, 9 Oct 2007 16:21:58 +0900
> To judge the timing for DAD, netif_carrier_ok() is used. However,
> there is a possibility that dev->qdisc stays noop_qdisc even if
> netif_carrier_ok() returns true. In that case, DAD NS is not sent out.
> We need to defer the IPv6 device initialization until a valid qdisc
> is specified.
>
> Signed-off-by: Mitsuru Chinen <mitch@linux.vnet.ibm.com>
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Thanks for submitting the fix.
Although Herbert is right that this does not fix the problem
universally, it does make things better, so I will apply this
patch.
Thanks!
^ permalink raw reply
* Re: [PATCH][NET-2.6.24] Remove double dev->flags checking when calling dev_close()
From: David Miller @ 2007-10-10 9:49 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <470B5D0E.9090202@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Tue, 09 Oct 2007 14:50:54 +0400
> The unregister_netdevice() and dev_change_net_namespace()
> both check for dev->flags to be IFF_UP before calling the
> dev_close(), but the dev_close() checks for IFF_UP itself,
> so remove those unneeded checks.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied, thanks Pavel.
^ permalink raw reply
* Re: [RFC PATCH net-2.6.24 0/3]: Attempt to fix lost_retrans brokeness
From: David Miller @ 2007-10-10 9:48 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: netdev, shemminger, takano
In-Reply-To: <Pine.LNX.4.64.0710091600300.3767@kivilampi-30.cs.helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Tue, 9 Oct 2007 16:03:29 +0300 (EEST)
> On Tue, 9 Oct 2007, Ilpo Järvinen wrote:
>
> > Lost_retrans handling of sacktag was found to be flawed, two
> > problems that were found have an intertwined solution. Fastpath
> > problem has existed since hints got added and the other problem
> > has probably been there even longer than that. ...This change
> > may add non-trivial processing cost.
> >
> > Initial sketch, only compile tested. This will become more and
> > more useful, when sacktag starts to process less and less skbs,
> > which hopefully happens quite soon... :-) Sadly enough it will
> > probably then be consuming part of the benefits we're able to
> > achieve by less skb walking...
> >
> > First one is trivial, so Dave might want to apply it already.
>
> Hmm, forgot to add -n to git-format-patch. Since it's currently
> RFC, I won't bother to resubmit with numbers unless somebody
> really wants that. Here's the correct ordering, if it's not
> obvious from the patches alone:
I'm going to leave the 2nd patches and 3rd patches alone for
now so they can cook a little bit longer.
Thanks!
^ permalink raw reply
* Re: [PATCH] [TCP]: Separate lost_retrans loop into own function
From: David Miller @ 2007-10-10 9:45 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: netdev, shemminger, takano
In-Reply-To: <11919324023846-git-send-email-ilpo.jarvinen@helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Tue, 9 Oct 2007 15:20:00 +0300
> Follows own function for each task principle, this is really
> somewhat separate task being done in sacktag. Also reduces
> indentation.
>
> In addition, added ack_seq local var to break some long
> lines & fixed coding style things.
>
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Applied, thanks Ilpo!
^ permalink raw reply
* Re: [RFC PATCH] [TCP]: Limit processing lost_retrans loop to work-to-do cases
From: David Miller @ 2007-10-10 9:44 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: netdev, shemminger, takano
In-Reply-To: <20071010.024403.116354578.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 10 Oct 2007 02:44:03 -0700 (PDT)
> From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
> Date: Tue, 9 Oct 2007 15:20:02 +0300
>
> > This addition of lost_retrans_low to tcp_sock might be
> > unnecessary, it's not clear how often lost_retrans worker is
> > executed when there wasn't work to do.
> >
> > Cc: TAKANO Ryousei <takano@axe-inc.co.jp>
> > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
>
> I wanted to apply this, but it doesn't go cleanly on top of
> net-2.6.24, can you respin this patch for me?
Nevermind, I mis-interpreted the ordering of the 3 patches,
sorry...
^ permalink raw reply
* Re: [RFC PATCH] [TCP]: Limit processing lost_retrans loop to work-to-do cases
From: David Miller @ 2007-10-10 9:44 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: netdev, shemminger, takano
In-Reply-To: <11919324033627-git-send-email-ilpo.jarvinen@helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Tue, 9 Oct 2007 15:20:02 +0300
> This addition of lost_retrans_low to tcp_sock might be
> unnecessary, it's not clear how often lost_retrans worker is
> executed when there wasn't work to do.
>
> Cc: TAKANO Ryousei <takano@axe-inc.co.jp>
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
I wanted to apply this, but it doesn't go cleanly on top of
net-2.6.24, can you respin this patch for me?
Thanks!
^ permalink raw reply
* Re: [PATCH] division-by-zero in inet_csk_get_port
From: David Miller @ 2007-10-10 9:35 UTC (permalink / raw)
To: aarapov; +Cc: den, netdev
In-Reply-To: <m31wc3l4ym.fsf@bandura.englab.brq.redhat.com>
From: Anton Arapov <aarapov@redhat.com>
Date: Wed, 10 Oct 2007 11:00:17 +0200
> Ok, I've got it, so we have to do the same with the following:
> quote from inet_hashtables.c and inet6_hashtables.c. I'll prepare the
> patch.
>
> And just a curious, does the /* Treat low > high as high == low */
> idea will keep after the sysctl will be patched?
I'm beginning to think that we should do the sysctl validation
in this patch too, instead of duplicating this grotty check
in all of these port selection functions.
^ permalink raw reply
* Re: [PATCH 1/8][BNX2X] resubmit as attachments: add bnx2x to Kconfig and Makefile
From: David Miller @ 2007-10-10 9:34 UTC (permalink / raw)
To: eliezert; +Cc: jeff, netdev, mchan
In-Reply-To: <1191946801.29746.89.camel@eliezer>
From: "Eliezer Tamir" <eliezert@broadcom.com>
Date: Tue, 09 Oct 2007 18:20:01 +0200
> Almost all of the zero-filled tables will be removed.
> The rest of the registers do need to be initialized.
>
> I agree that the number of registers that needs to be initialized is
> huge, but that is caused by the way the hardware was designed.
>
> The values for the initialization come from several sources:
> Some are derived from HW code (the XML files used to derive the verilog
> code),
> Others (along with much of the machine generated .h files) are generated
> at microcode build time, adding a microcode routine will cause the init
> values to change, using a new variable can cause an .h file to change.
> In the last group which is very small, are registers that are controlled
> by the driver.
>
> The values in this file really are machine generated, they really are
> not meant to be modified directly by editing the file.
>
> The registers that are under the driver's control are in the main .c
> and .h files.
...
> The idle check code is not a manufacturing test, it is meant to help
> debug the driver and microcode.
> If the driver sends an invalid command to one of the CPUs which then
> chokes on it, this will tell you which one of them died and the general
> whereabouts of the problem. (ingress CPU X is stuck because output queue
> Y is full)
...
> ( Michael has showed me the trick of how to post with evolution, so I
> hope that the mangled patch problem is behind us and I think that I can
> now post everything without a problem, Hallelujah!)
Thanks for the explanations, I look forward to your next
submission.
^ permalink raw reply
* Re: [PATCH 6/6][NET-2.6.24] Make the sunrpc use the seq_open_private()
From: David Miller @ 2007-10-10 9:33 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel, neilb
In-Reply-To: <470BA687.8030202@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Tue, 09 Oct 2007 20:04:23 +0400
> Just switch to the consolidated code.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
> Cc: Neil Brown <neilb@cse.unsw.edu.au>
Applied.
^ permalink raw reply
* Re: [PATCH 5/6][NET-2.6.24] Make the IRDA use the seq_open_private()
From: David Miller @ 2007-10-10 9:33 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel, samuel
In-Reply-To: <470BA5DC.8060905@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Tue, 09 Oct 2007 20:01:32 +0400
> Just switch to the consolidated code
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
> Cc: Samuel Ortiz <samuel@sortiz.org>
Applied.
^ permalink raw reply
* Re: [PATCH 4/6][NET-2.6.24] Make decnet code use the seq_open_private()
From: David Miller @ 2007-10-10 9:33 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel, patrick
In-Reply-To: <470BA56A.6020903@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Tue, 09 Oct 2007 19:59:38 +0400
> Just switch to the consolidated code.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
> Cc: Patrick Caulfield <patrick@tykepenguin.com>
Applied.
^ permalink raw reply
* Re: [PATCH 3/6][NET-2.6.24] Make netfilter code use the seq_open_private
From: David Miller @ 2007-10-10 9:33 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel, kaber
In-Reply-To: <470BA4E9.7000909@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Tue, 09 Oct 2007 19:57:29 +0400
> Just switch to the consolidated calls.
>
> ipt_recent() has to initialize the private, so use
> the __seq_open_private() helper.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
> Cc: Patrick McHardy <kaber@trash.net>
Applied.
^ permalink raw reply
* Re: [PATCH 2/6][NET-2.6.24] Make core networking code use seq_open_private
From: David Miller @ 2007-10-10 9:32 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <470BA470.2010603@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Tue, 09 Oct 2007 19:55:28 +0400
> This concerns the ipv4 and ipv6 code mostly, but also the netlink
> and unix sockets.
>
> The netlink code is an example of how to use the __seq_open_private()
> call - it saves the net namespace on this private.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied.
^ permalink raw reply
* Re: [PATCH 1/6][NET-2.6.24] Introduce the seq_open_private()
From: David Miller @ 2007-10-10 9:32 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <470BA3DA.6050905@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Tue, 09 Oct 2007 19:52:58 +0400
> This function allocates the zeroed chunk of memory and
> call seq_open(). The __seq_open_private() helper returns
> the allocated memory to make it possible for the caller
> to initialize it.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied, nice cleanup Pavel.
^ permalink raw reply
* Re: [ofa-general] Re: [PATCH 2/3][NET_BATCH] net core use batching
From: David Miller @ 2007-10-10 9:25 UTC (permalink / raw)
To: andi
Cc: hadi, shemminger, jeff, johnpol, herbert, gaagaan, Robert.Olsson,
netdev, rdreier, peter.p.waskiewicz.jr, mcarlson, jagana, general,
mchan, tgraf, randy.dunlap, sri, kaber
In-Reply-To: <20071010091644.GA9807@one.firstfloor.org>
From: Andi Kleen <andi@firstfloor.org>
Date: Wed, 10 Oct 2007 11:16:44 +0200
> > A 256 entry TX hw queue fills up trivially on 1GB and 10GB, but if you
>
> With TSO really?
Yes.
> > increase the size much more performance starts to go down due to L2
> > cache thrashing.
>
> Another possibility would be to consider using cache avoidance
> instructions while updating the TX ring (e.g. write combining
> on x86)
The chip I was working with at the time (UltraSPARC-IIi) compressed
all the linear stores into 64-byte full cacheline transactions via
the store buffer.
It's true that it would allocate in the L2 cache on a miss, which
is different from your suggestion.
In fact, such a thing might not pan out well, because most of the time
you write a single descriptor or two, and that isn't a full cacheline,
which means a read/modify/write is the only coherent way to make such
a write to RAM.
Sure you could batch, but I'd rather give the chip work to do unless
I unequivocably knew I'd have enough pending to fill a cacheline's
worth of descriptors. And since you suggest we shouldn't queue in
software... :-)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox