From: jamal <[EMAIL PROTECTED]>
Date: Mon, 17 Sep 2007 08:51:40 -0400
> On Sun, 2007-16-09 at 20:13 -0700, David Miller wrote:
>
> > This only makes sense for devices which can 1) scatter-gather
> > and 2) checksum on transmit.
>
> If you have knowledge there are enough descriptors in the driv
On Sun, 2007-16-09 at 20:13 -0700, David Miller wrote:
> What Herbert and I want to do is basically turn on TSO for
> devices that can't do it in hardware, and rely upon the GSO
> framework to do the segmenting in software right before we
> hit the device.
Sensible.
> This only makes sense for
[Removing Jeff as requested from thread :) ]
Hi Dave,
David Miller <[EMAIL PROTECTED]> wrote on 09/17/2007 07:55:02 AM:
> From: jamal <[EMAIL PROTECTED]>
> Date: Sun, 16 Sep 2007 22:14:21 -0400
>
> > I still think this work - despite my vested interest - needs more
> > scrutiny from a performanc
Hi Dave,
David Miller <[EMAIL PROTECTED]> wrote on 09/17/2007 04:47:48 AM:
> The only major complaint I have about this patch series is that
> the IPoIB part should just be one big changeset. Otherwise the
> tree is not bisectable, for example the initial ipoib header file
> change breaks the bu
From: jamal <[EMAIL PROTECTED]>
Date: Sun, 16 Sep 2007 23:01:43 -0400
> I think GSO is still useful on top of this.
> In my patches anything with gso gets put into the batch list and shot
> down the driver. Ive never considered checking whether the nic is TSO
> capable, that may be something worth
On Sun, 2007-16-09 at 19:25 -0700, David Miller wrote:
> There are tertiary issues I'm personally interested in, for example
> how well this stuff works when we enable software GSO on a non-TSO
> capable card.
>
> In such a case the GSO segment should be split right before we hit the
> driver and
From: jamal <[EMAIL PROTECTED]>
Date: Sun, 16 Sep 2007 22:14:21 -0400
> I still think this work - despite my vested interest - needs more
> scrutiny from a performance perspective.
Absolutely.
There are tertiary issues I'm personally interested in, for example
how well this stuff works when we e
On Sun, 2007-16-09 at 18:02 -0700, David Miller wrote:
> I do.
>
> And I'm reviewing and applying several hundred patches a day.
>
> What's the point? :-)
Reading the commentary made me think you were about to swallow that with
one more change by the time i wake up;->
I still think this work -
From: jamal <[EMAIL PROTECTED]>
Date: Sun, 16 Sep 2007 20:29:18 -0400
> On Sun, 2007-16-09 at 16:17 -0700, David Miller wrote:
>
> > The only major complaint I have about this patch series is that
> > the IPoIB part should just be one big changeset.
>
> Dave, you do realize that i have been inv
On Sun, 2007-16-09 at 16:17 -0700, David Miller wrote:
> The only major complaint I have about this patch series is that
> the IPoIB part should just be one big changeset.
Dave, you do realize that i have been investing my time working on
batching as well, right?
cheers,
jamal
-
To unsubscri
From: Krishna Kumar <[EMAIL PROTECTED]>
Date: Fri, 14 Sep 2007 14:30:58 +0530
> This set of patches implements the batching xmit capability, and
> adds support for batching in IPoIB and E1000 (E1000 driver changes
> is ported, thanks to changes taken from Jamal's code from an old
> kernel).
The o
Hi Krishna.
On Fri, Sep 14, 2007 at 02:30:58PM +0530, Krishna Kumar ([EMAIL PROTECTED])
wrote:
>
> The retransmission problem reported earlier seems to happen when mthca is
> used as the underlying device, but when I tested ehca the retransmissions
> dropped to normal levels (around 2 ti
This set of patches implements the batching xmit capability, and adds support
for batching in IPoIB and E1000 (E1000 driver changes is ported, thanks to
changes taken from Jamal's code from an old kernel).
List of changes from previous revision:
1. [Dave] E
13 matches
Mail list logo
