On Friday 22 September 2006 10:44, Andrew Gallatin wrote:
>
> Between TSO and your sendfile changes, things are looking up!
>
> Here are some Myri10GbE 1500 byte results from a 1.8GHz UP
> FreeBSD/amd64 machine (AMD Athlon(tm) 64 Processor 3000+) sending to a
> 2.0GHz SMP Linux/x86_64 machine (A
> The congestion window is increased based on the ACK's received. TSO
> is only done on the send side and only up to the current congestion
> window. I have been careful not to get any changes in congestion
> control behavior with TSO. (Which does not mean that there may be
> other bugs lurking
David Malone wrote:
On Fri, Sep 22, 2006 at 11:48:23PM +0100, Robert Watson wrote:
The impact of TSO is clearly dramatic, especially when combined with the
patch, but I'm a bit concerned by the drop in performance in the patched
non-TSO case. For network cards which will always have TSO enable
Robert Watson wrote:
On Sat, 23 Sep 2006, Andre Oppermann wrote:
Without patch:
87380 393216 39321610.00 2163.08 100.00 19.353.787
1.466 Without patch + TSO:
87380 393216 39321610.00 4367.18 71.5442.071.342
1.578 With patch:
87380 393216 39321610.01
On Fri, Sep 22, 2006 at 11:48:23PM +0100, Robert Watson wrote:
> The impact of TSO is clearly dramatic, especially when combined with the
> patch, but I'm a bit concerned by the drop in performance in the patched
> non-TSO case. For network cards which will always have TSO enabled, this
> isn't
Andre Oppermann writes:
> Andrew Gallatin wrote:
> >
> > Between TSO and your sendfile changes, things are looking up!
> >
> > Here are some Myri10GbE 1500 byte results from a 1.8GHz UP
> > FreeBSD/amd64 machine (AMD Athlon(tm) 64 Processor 3000+) sending to a
> > 2.0GHz SMP Linux/x86_64
On Sat, 23 Sep 2006, Andre Oppermann wrote:
Without patch:
87380 393216 39321610.00 2163.08 100.00 19.353.787
1.466 Without patch + TSO:
87380 393216 39321610.00 4367.18 71.5442.071.342
1.578 With patch:
87380 393216 39321610.01 1882.73 86.15
Andrew Gallatin wrote:
Between TSO and your sendfile changes, things are looking up!
Here are some Myri10GbE 1500 byte results from a 1.8GHz UP
FreeBSD/amd64 machine (AMD Athlon(tm) 64 Processor 3000+) sending to a
2.0GHz SMP Linux/x86_64 machine (AMD Athlon(tm) 64 X2 Dual Core Processor
3800
Between TSO and your sendfile changes, things are looking up!
Here are some Myri10GbE 1500 byte results from a 1.8GHz UP
FreeBSD/amd64 machine (AMD Athlon(tm) 64 Processor 3000+) sending to a
2.0GHz SMP Linux/x86_64 machine (AMD Athlon(tm) 64 X2 Dual Core Processor
3800+) running 26.17.7smp and
Andre Oppermann wrote:
Gleb Smirnoff wrote:
Is there RELENG_6 version of your patch. If there is one, we can test it
quite extensively.
This patch does not fully apply to RELENG_6 as there are some small changes
and a bit locking differences. It shouldn't be too hard to adapt it. You
won't g
On Thu, 21 Sep 2006, Peter Jeremy wrote:
On Wed, 2006-Sep-20 23:59:13 +0200, Andre Oppermann wrote:
I have rewritten kern_sendfile() to work in two loops, the inner which
turns as many pages into mbufs as it can up to the free send socket buffer
space.
The 64K blocks sounds good but how doe
On Thu, 21 Sep 2006, Andre Oppermann wrote:
There should be unconditional M_NOWAIT. Oops, the M_DONTWAIT in the current
code is incorrect. It is present since rev. 1.171. If the m_uiotombuf()
fails the current code returns from syscall without error! Before rev.
1.171, there wasn't m_uiotombu
Peter Jeremy wrote:
On Wed, 2006-Sep-20 23:59:13 +0200, Andre Oppermann wrote:
I have rewritten kern_sendfile() to work in two loops, the inner which turns
as many pages into mbufs as it can up to the free send socket buffer space.
The 64K blocks sounds good but how does this interact with TCP
Gleb Smirnoff wrote:
Andre,
On Wed, Sep 20, 2006 at 11:59:13PM +0200, Andre Oppermann wrote:
A> I have rewritten kern_sendfile() to work in two loops, the inner which turns
A> as many pages into mbufs as it can up to the free send socket buffer space.
A> The outer loop then drops the whole mbu
Andre,
On Wed, Sep 20, 2006 at 11:59:13PM +0200, Andre Oppermann wrote:
A> I have rewritten kern_sendfile() to work in two loops, the inner which turns
A> as many pages into mbufs as it can up to the free send socket buffer space.
A> The outer loop then drops the whole mbuf chain into the send s
On Thu, Sep 21, 2006 at 05:59:03PM +1000, Peter Jeremy wrote:
> On Wed, 2006-Sep-20 23:59:13 +0200, Andre Oppermann wrote:
> >I have rewritten kern_sendfile() to work in two loops, the inner which turns
> >as many pages into mbufs as it can up to the free send socket buffer space.
>
> The 64K bloc
On Wed, 2006-Sep-20 23:59:13 +0200, Andre Oppermann wrote:
>I have rewritten kern_sendfile() to work in two loops, the inner which turns
>as many pages into mbufs as it can up to the free send socket buffer space.
The 64K blocks sounds good but how does this interact with TCP slow
start? Is there
The recent addition of TSO (TCP Segmentation Offload) has highlighted some
shortcommings in our sendfile(2) kernel implementation. The current code
simply loops over the file, turns each 4K page into an mbuf and sends it
off. This has the effect that TSO can only generate 2 packets per send
inst
18 matches
Mail list logo
