* Re: [ofa-general] Re: [PATCH 2/3][NET_BATCH] net core use batching
From: Andi Kleen @ 2007-10-10 9:16 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: <20071009.175025.59469417.davem@davemloft.net>
> A 256 entry TX hw queue fills up trivially on 1GB and 10GB, but if you
With TSO really?
> 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)
-Andi
^ 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
* 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: [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 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 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 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 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 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] 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: [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: [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: [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 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][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: [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: [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] 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: [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: 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
* [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: [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
* 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: 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: 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
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