Bug 24959
| Summary: | [patch] proper TCP_NOPUSH/TCP_CORK compatibility | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Tony Finch <dot> | ||||||
| Component: | kern | Assignee: | freebsd-net (Nobody) <net> | ||||||
| Status: | Closed Feedback Timeout | ||||||||
| Severity: | Affects Only Me | CC: | hiren | ||||||
| Priority: | Normal | ||||||||
| Version: | 4.2-STABLE | ||||||||
| Hardware: | Any | ||||||||
| OS: | Any | ||||||||
| Attachments: |
|
||||||||
<<On Thu, 08 Feb 2001 22:27:25 +0000, Tony Finch <dot@dotat.at> said: > * TCP_NOPUSH has additional T/TCP-related semantics that may be > undesirable in an application that only wants the TCP_CORK > semantics. If the option is set on a listening socket then it > enables TAO. I don't believe this is material, since Transaction TCP is disabled by default. Furthermore, I would prefer to avoid introducing such a poorly-named option. -GAWollman Garrett Wollman <wollman@khavrinen.lcs.mit.edu> wrote: ><<On Thu, 08 Feb 2001 22:27:25 +0000, Tony Finch <dot@dotat.at> said: > >> * TCP_NOPUSH has additional T/TCP-related semantics that may be >> undesirable in an application that only wants the TCP_CORK >> semantics. If the option is set on a listening socket then it >> enables TAO. > >I don't believe this is material, since Transaction TCP is disabled by >default. I still think it's a bad idea to mix the two features together like this: applications should be able to get predictably non-T/TCP behaviour if they so choose. How about keeping the TCP_NOPUSH part of the functionality under that name and making a TCP_ALLOWTAO option for the listen-side functionality? Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at DOGGER FISHER GERMAN BIGHT HUMBER THAMES: NORTHERLY 4 OR 5, OCCASIONALLY 6 AT FIRST IN GERMAN BIGHT HUMBER AND THAMES, BECOMING VARIABLE 3. WINTRY SHOWERS. GOOD. <<On Fri, 9 Feb 2001 01:35:01 +0000, Tony Finch <dot@dotat.at> said: > I still think it's a bad idea to mix the two features together like > this: applications should be able to get predictably non-T/TCP > behaviour if they so choose. I'm still puzzled as to what difference you think this makes to an application. -GAWollman Garrett Wollman <wollman@khavrinen.lcs.mit.edu> wrote: ><<On Fri, 9 Feb 2001 01:35:01 +0000, Tony Finch <dot@dotat.at> said: > >> I still think it's a bad idea to mix the two features together like >> this: applications should be able to get predictably non-T/TCP >> behaviour if they so choose. > >I'm still puzzled as to what difference you think this makes to an >application. According to the CVS log the reason the test for TF_NOPUSH was added to tcp_listen was so that applications would disallow T/TCP connections by default even if net.inet.tcp.rfc1644 is turned on. Only applications explicitly coded to accept T/TCP connections would do so. I guess this is because T/TCP has a bad reputation. So if servers start turning on TCP_NOPUSH for performance reasons then they also as a side effect start accepting T/TCP TAO connections, which some people would consider to be a bug. Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at NORTH UTSIRE SOUTH UTSIRE FORTIES: NORTHWEST BACKING SOUTH OR SOUTHWEST 4 OR 5, DECREASING 3 FOR A TIME. SNOW SHOWERS. MAINLY GOOD. Responsible Changed From-To: freebsd-bugs->jesper will work on this Responsible Changed From-To: jesper->freebsd-net Throw this one open to the -net list Responsible Changed From-To: freebsd-net->andre Take over. State Changed From-To: open->feedback Is this change still needed? Or has the application issue been addressed in some other way? Responsible Changed From-To: andre->kmacy Is this change still needed? Or has the application issue been addressed in some other way? Responsible Changed From-To: kmacy->freebsd-net kmacy has asked for all of his PRs to be reassigned back to the pool. To submitter: feedback on this was requested. If you did provide feedback then it doesn't appear to have made it into the PR trail - could you please resend it? Please reopen if needed. |
Jonathan Lemon recently committed a fix to the implementation of TCP_NOPUSH that expedites the output of the last packet in a sequence (rev. 1.53 of tcp_usrreq.c). However there are a number of problems with that commit, as follows: * the change hsan't been documented * although the new functionality is similar to Linux's TCP_CORK, the Linuxulator hasn't been updated to implement that support. * TCP_NOPUSH has additional T/TCP-related semantics that may be undesirable in an application that only wants the TCP_CORK semantics. If the option is set on a listening socket then it enables TAO. This patch introduces a new TCP option called TCP_CORK which is intended to be exactly the same as the Linux version. The old tcp_output part of the TCP_NOPUSH functionality is renamed to use TCP_CORK. TCP_NOPUSH is now implemented as a superset of TCP_CORK that also includes the T/TCP functionality in tcp_input. I've included two patches below, one against -STABLE and one against -CURRENT. They're the same apart from the change in tcp_usrreq.c in -CURRENT. Fix: -------------------------------------------------------------------------------- This patch is against RELENG_4 -------------------------------------------------------------------------------- This patch is against HEAD