On Mon, 13 Sep 2010, Andre Oppermann wrote:
Hey,
When a TCP connection via loopback back to localhost is made the whole
send, segmentation and receive path (with larger packets though) is still
executed. This has some considerable overhead.
To short-circuit the send and receive sockets on
On Mon, 13 Sep 2010, Andre Oppermann wrote:
Preliminary testing (with WITNESS and INVARIANTS enabled) has shown stable
operation and a rough doubling of the throughput on loopback connections.
I've tested most socket teardown cases and it behaves fine. I'm not entirely
sure I've got all
On 15.09.2010 17:19, Bjoern A. Zeeb wrote:
On Mon, 13 Sep 2010, Andre Oppermann wrote:
Hey,
When a TCP connection via loopback back to localhost is made the whole
send, segmentation and receive path (with larger packets though) is still
executed. This has some considerable overhead.
To
Great,
This will maybe kill the long time debate about my loopback is slow vs linux
To have the best of both world what about a socket option to enable/disable
fusing:
can be useful when you need to see some connection packetized.
Fabien
On 13 sept. 2010, at 13:33, Andre Oppermann wrote:
Fabien Thomas wrote:
Great,
This will maybe kill the long time debate about my loopback is slow vs
linux
To have the best of both world what about a socket option to
enable/disable fusing:
can be useful when you need to see some connection packetized.
To chime in, I had a slow loopback
Hello!
On Tue, Sep 14, 2010 at 12:12:03PM +0200, Ian FREISLICH wrote:
Fabien Thomas wrote:
Great,
This will maybe kill the long time debate about my loopback is slow vs
linux
To have the best of both world what about a socket option to
enable/disable fusing:
can be useful when
On 14 sept. 2010, at 17:41, Andre Oppermann wrote:
On 14.09.2010 11:18, Fabien Thomas wrote:
Great,
This will maybe kill the long time debate about my loopback is slow vs
linux
To have the best of both world what about a socket option to enable/disable
fusing:
can be useful when you
On 14.09.2010 11:18, Fabien Thomas wrote:
Great,
This will maybe kill the long time debate about my loopback is slow vs linux
To have the best of both world what about a socket option to enable/disable
fusing:
can be useful when you need to see some connection packetized.
A sysctl to that
On 14.09.2010 12:12, Ian FREISLICH wrote:
Fabien Thomas wrote:
Great,
This will maybe kill the long time debate about my loopback is slow vs
linux
To have the best of both world what about a socket option to
enable/disable fusing:
can be useful when you need to see some connection packetized.
On 14.09.2010 12:35, Maxim Dounin wrote:
Hello!
On Tue, Sep 14, 2010 at 12:12:03PM +0200, Ian FREISLICH wrote:
Fabien Thomas wrote:
Great,
This will maybe kill the long time debate about my loopback is slow vs
linux
To have the best of both world what about a socket option to
enable/disable
On 14.09.2010 18:08, Fabien Thomas wrote:
On 14 sept. 2010, at 17:41, Andre Oppermann wrote:
On 14.09.2010 11:18, Fabien Thomas wrote:
Great,
This will maybe kill the long time debate about my loopback is slow vs linux
To have the best of both world what about a socket option to
When a TCP connection via loopback back to localhost is made the whole
send, segmentation and receive path (with larger packets though) is still
executed. This has some considerable overhead.
To short-circuit the send and receive sockets on localhost TCP connections
I've made a proof-of-concept
In message 4c8e0c1e.2020...@networx.ch, Andre Oppermann writes:
To short-circuit the send and receive sockets on localhost TCP connections
I've made a proof-of-concept patch that directly places the data in the
other side's socket buffer without doing any packetization and other protocol
overhead
On 13.09.2010 14:45, Poul-Henning Kamp wrote:
In message4c8e0c1e.2020...@networx.ch, Andre Oppermann writes:
To short-circuit the send and receive sockets on localhost TCP connections
I've made a proof-of-concept patch that directly places the data in the
other side's socket buffer without
14 matches
Mail list logo
