RE: tcp_push_pending_frames() without TCP_CORK or TCP_NODELAY

[Robert White]

I thought about turning cork on an off.  While it does essentially burp the transfer
into larger frames it is still flawed for my usage for several reasons.

Omitting the uninteresting parts and giving a real-but-partial example...

In one of the applications I am stuck with I have a USB device on one machine that I
am tunneling onto another.  The reasons I can't just plug the USB device into the
other machine are tedious.  The USB device "bursts" 32 characters at a time maximum.
I also send monitoring information "on the side band" (on the same socket in sequence
with the data but marked as control information) on occasion, which is where my
application-level framing comes into play.  Normally it is fine to just use TCP as-is
and let things Nagle normally and live with the induced delay.

Now consider running PPP on that device over that tunnel.  Again it is uninteresting
why I can't run pppd on the computer local to the USB device.  If the TCP stream is
flushed when any 32-or-less byte burst ends with the PPP framing character, the data
throughput on ppp interface abstracted across the tunnel rises considerably.

In the current implementation, the only flush available in TCP is to turn nagle off
and then back on, which over the course of a tunnel lifespan adds a significant
number of syscalls.

1) I am not really interested in delaying the front of the frames as much as I am
interested in expediting the end of the frames.  So I don't actually want to cork the
stream, I just want to flush it under easily detectable conditions.

2) There are times when the frames can be larger than the Ethernet MTU so corking
starts getting counter-productive.

3) There are times when the right moment to release a cork isn't determinable (as I
don't want the tunnel in the business of guessing whether the overlying user is or
isn't in ppp mode).

4) Cork-then-uncork would still end up with two syscalls instead of one.

5) Just turning Nagle off completely begins to scale rather poorly as device count
increases because of the large number of 32 byte payloads.

I can imagine other protocols and applications (near-real-time signaling or games?)
that could benefit from a flush operation on the TCP stack; and indeed I have another
one in force that is less easy to explain (without getting really boring 8-) than the
above.


Rob White,
Casabyte, Inc.

-----Original Message-----
From: David S. Miller [mailto:davem@xxxxxxxxxx] 
Sent: Thursday, July 29, 2004 7:37 PM
To: Robert White
Cc: linux-kernel@xxxxxxxxxxxxxxx
Subject: Re: tcp_push_pending_frames() without TCP_CORK or TCP_NODELAY


Turn off NAGLE, and flip TCP_CORK on and off around the sequences.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/