From: Andrew Gallatin [EMAIL PROTECTED]
Date: Tue, 20 Nov 2007 06:47:57 -0500
David Miller wrote:
From: Herbert Xu [EMAIL PROTECTED]
Date: Tue, 20 Nov 2007 14:09:18 +0800
David Miller [EMAIL PROTECTED] wrote:
Fundamentally, I really don't like this change, it batches to the
David Miller wrote:
From: Herbert Xu [EMAIL PROTECTED]
Date: Tue, 20 Nov 2007 14:09:18 +0800
David Miller [EMAIL PROTECTED] wrote:
Fundamentally, I really don't like this change, it batches to the
point where it begins to erode the natural ACK clocking of TCP, and I
therefore am very
Hi.
On Tue, Nov 20, 2007 at 08:27:05AM -0500, Andrew Gallatin ([EMAIL PROTECTED])
wrote:
Hmm.. rather than a global tunable, what if it was a
network driver managed tunable which toggled a flag in the
lro_mgr features? Would that be better?
What about ethtool control to set LRO_simple and
David Miller wrote:
From: Andrew Gallatin [EMAIL PROTECTED]
Date: Tue, 20 Nov 2007 06:47:57 -0500
David Miller wrote:
From: Herbert Xu [EMAIL PROTECTED]
Date: Tue, 20 Nov 2007 14:09:18 +0800
David Miller [EMAIL PROTECTED] wrote:
Fundamentally, I really don't like this change,
On Tue, Nov 20, 2007 at 09:50:56PM +0800, Herbert Xu ([EMAIL PROTECTED]) wrote:
On Tue, Nov 20, 2007 at 04:35:09PM +0300, Evgeniy Polyakov wrote:
On Tue, Nov 20, 2007 at 08:27:05AM -0500, Andrew Gallatin ([EMAIL
PROTECTED]) wrote:
Hmm.. rather than a global tunable, what if it was a
On Tue, Nov 20, 2007 at 04:35:09PM +0300, Evgeniy Polyakov wrote:
On Tue, Nov 20, 2007 at 08:27:05AM -0500, Andrew Gallatin ([EMAIL PROTECTED])
wrote:
Hmm.. rather than a global tunable, what if it was a
network driver managed tunable which toggled a flag in the
lro_mgr features? Would
On Tue, Nov 20, 2007 at 05:03:12PM +0300, Evgeniy Polyakov wrote:
For software lro I agree, but this looks exactly like gso/tso case and
additional tweak for software gso. Having it per-system is fine, and I
believe no one should ever care that some distro will do bad/good things
with it.
On Tue, Nov 20, 2007 at 10:08:31PM +0800, Herbert Xu ([EMAIL PROTECTED]) wrote:
Of course we still have the problem with the option in general
that Dave raised. That is this may cause the proliferation of
TCP receiver behaviour that may be undesirable.
Yes, it results in bursts of traffic
David Miller wrote:
From: Andrew Gallatin [EMAIL PROTECTED]
Date: Tue, 23 Oct 2007 11:11:55 -0400
I've attached a patch which adds support to inet_lro for aggregating
pure acks.
I've applied this patch to net-2.6.25... but!
This needs some serious thinking. What this patch ends up doing
From: Rick Jones [EMAIL PROTECTED]
Date: Tue, 20 Nov 2007 11:45:54 -0800
Sounds like one might as well go ahead and implement HP-UX/Solaris-like
ACK sending avoidance at the receiver and not bother with LRO-ACK on the
sender.
In some experiements a while back I thought I saw that LRO on
On Tue, 20 Nov 2007, Andrew Gallatin wrote:
David Miller wrote:
From: Andrew Gallatin [EMAIL PROTECTED]
Date: Tue, 20 Nov 2007 06:47:57 -0500
David Miller wrote:
From: Herbert Xu [EMAIL PROTECTED]
Date: Tue, 20 Nov 2007 14:09:18 +0800
David Miller [EMAIL
From: Andrew Gallatin [EMAIL PROTECTED]
Date: Tue, 23 Oct 2007 11:11:55 -0400
I've attached a patch which adds support to inet_lro for aggregating
pure acks.
I've applied this patch to net-2.6.25... but!
This needs some serious thinking. What this patch ends up doing is creating
big
From: Herbert Xu [EMAIL PROTECTED]
Date: Tue, 20 Nov 2007 14:09:18 +0800
David Miller [EMAIL PROTECTED] wrote:
Fundamentally, I really don't like this change, it batches to the
point where it begins to erode the natural ACK clocking of TCP, and I
therefore am very likely to revert it
David Miller [EMAIL PROTECTED] wrote:
Fundamentally, I really don't like this change, it batches to the
point where it begins to erode the natural ACK clocking of TCP, and I
therefore am very likely to revert it before merging to Linus.
Perhaps make it a tunable that defaults to off?
Cheers,
Hi,
We recently did some performance comparisons between the new inet_lro
LRO support in the kernel, and our Myri10GE in-driver LRO.
For receive, we found they were nearly identical. However, for
transmit, we found that Myri10GE's LRO shows much lower CPU
utilization. We traced the CPU
15 matches
Mail list logo
