From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753457AbbKBJSj (ORCPT ); Mon, 2 Nov 2015 04:18:39 -0500 Received: from smtp-out4.electric.net ([192.162.216.184]:56000 "EHLO smtp-out4.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751571AbbKBJSf convert rfc822-to-8bit (ORCPT ); Mon, 2 Nov 2015 04:18:35 -0500 From: David Laight To: "'bro.devel+kernel@gmail.com'" , Yuchung Cheng CC: Andreas Petlund , Neal Cardwell , "David S. Miller" , "Alexey Kuznetsov" , James Morris , "Hideaki YOSHIFUJI" , Patrick McHardy , Jonathan Corbet , Eric Dumazet , "Tom Herbert" , Paolo Abeni , Erik Kline , Hannes Frederic Sowa , Al Viro , Jiri Pirko , Alexander Duyck , Florian Westphal , Daniel Lee , Marcelo Ricardo Leitner , "Daniel Borkmann" , Willem de Bruijn , =?Windows-1252?Q?Linus_L=FCssing?= , "linux-doc@vger.kernel.org" , LKML , Netdev , "linux-api@vger.kernel.org" , Carsten Griwodz , =?Windows-1252?Q?P=E5l_Halvorsen?= , Jonas Markussen , Kristian Evensen , Kenneth Klette Jonassen Subject: RE: [PATCH RFC net-next 2/2] tcp: Add Redundant Data Bundling (RDB) Thread-Topic: [PATCH RFC net-next 2/2] tcp: Add Redundant Data Bundling (RDB) Thread-Index: AQHREpzELHW12Ns+A0OejBNOpGG5QZ6IdVqw Date: Mon, 2 Nov 2015 09:18:20 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6D1CBC86C4@AcuExch.aculab.com> References: <1445633413-3532-1-git-send-email-bro.devel+kernel@gmail.com> <3710572.sJUWpao1xp@bro-compal> In-Reply-To: <3710572.sJUWpao1xp@bro-compal> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.99.200] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Outbound-IP: 213.249.233.130 X-Env-From: David.Laight@ACULAB.COM X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Bendik Rønning Opstad > Sent: 29 October 2015 22:54 ... > > > > The semantics of the tp->nonagle bits are already a bit complex. My > > > > sense is that having a setsockopt of TCP_RDB transparently modify the > > > > nagle behavior is going to add more extra complexity and unanticipated > > > > behavior than is warranted given the slight possible gain in > > > > convenience to the app writer. What about a model where the > > > > application user just needs to remember to call > > > > setsockopt(TCP_NODELAY) if they want the TCP_RDB behavior to be > > > > sensible? I see your nice tests at > > > > > > > > https://github.com/bendikro/packetdrill/commit/9916b6c53e33dd04329d29b > > > > 7d8baf703b2c2ac1b> > > > > > are already doing that. And my sense is that likewise most > > > > well-engineered "thin stream" apps will already be using > > > > setsockopt(TCP_NODELAY). Is that workable? > > This is definitely workable. I agree that it may not be an ideal solution to > have TCP_RDB disable Nagle, however, it would be useful with a way to easily > enable RDB and disable Nagle. If enabling RDB disables Nagle, then what happens when you turn RDB back off? David