From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753726Ab0BRJYl (ORCPT ); Thu, 18 Feb 2010 04:24:41 -0500 Received: from courier.cs.helsinki.fi ([128.214.9.1]:41540 "EHLO mail.cs.helsinki.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752788Ab0BRJYj (ORCPT ); Thu, 18 Feb 2010 04:24:39 -0500 Date: Thu, 18 Feb 2010 11:24:38 +0200 (EET) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@melkinpaasi.cs.helsinki.fi To: Andreas Petlund cc: Franco Fichtner , Netdev , eric.dumazet@gmail.com, hannemann@nets.rwth-aachen.de, LKML , shemminger@vyatta.com, william.allen.simpson@gmail.com, damian@tvk.rwth-aachen.de, ebiederm@xmission.com, David Miller Subject: Re: [net-next PATCH v4 2/3] net: TCP thin linear timeouts In-Reply-To: <4B7D05ED.4060900@simula.no> Message-ID: References: <4B7AAE69.8020701@simula.no> <20100217.163255.133898079.davem@davemloft.net> <4B7CFDE4.4010003@simula.no> <4B7D01CE.1030101@lastsummer.de> <4B7D05ED.4060900@simula.no> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; boundary="-696230645-638774431-1266484965=:9961" Content-ID: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---696230645-638774431-1266484965=:9961 Content-Type: TEXT/PLAIN; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT Content-ID: On Thu, 18 Feb 2010, Andreas Petlund wrote: > On 02/18/2010 10:09 AM, Ilpo Järvinen wrote: > > On Thu, 18 Feb 2010, Franco Fichtner wrote: > > > >> Andreas Petlund wrote: > >>> On 02/18/2010 09:41 AM, Ilpo Järvinen wrote: > >>> > >>>> On Wed, 17 Feb 2010, David Miller wrote: > >>>> > >>>> > >>>>> From: Andreas Petlund > >>>>> Date: Tue, 16 Feb 2010 15:40:41 +0100 > >>>>> > >>>>> > >>>>>> @@ -341,6 +342,8 @@ struct tcp_sock { > >>>>>> u16 advmss; /* Advertised MSS > >>>>>> */ > >>>>>> u8 frto_counter; /* Number of new acks after RTO */ > >>>>>> u8 nonagle; /* Disable Nagle algorithm? > >>>>>> */ > >>>>>> + u8 thin_lto : 1,/* Use linear timeouts for thin > >>>>>> streams */ > >>>>>> + thin_undef : 7; > >>>>>> > >>>>> There is now a gap of 3 unused bytes here in this critical > >>>>> core TCP socket data structure. > >>>>> > >>>>> Please either find a way to avoid this hole, or document > >>>>> it with a comment. > >>>>> > >>>> There would be multiple bits free for use in both frto_counter and nonagle > >>>> byte. > >>>> > >>>> > >>> > >>> I was playing aroud with this setup: > >>> > >>> ========= > >>> u8 nonagle : 4,/* Disable Nagle algorithm? */ > >>> thin_lto : 1,/* Use linear timeouts for thin streams */ > >>> thin_dupack : 1,/* Fast retransmit on first dupack */ > >>> thin_undef : 2; > >>> ========= > >>> > >>> Do you think that would do the trick? > >>> > >> > >> According to Ilpo, it would be ok to reduce both ftro_counter and > >> nonagle, so why not join all these into u16 and leave the remaining > >> free bits documented for other people. Like this: > >> > >> u16 frto_counter:x; /* Number of new acks after RTO */ > >> u16 nonagle:y; /* Disable Nagle algorithm? */ > >> u16 thin_lto:1; /* Use linear timeouts for thin streams */ > >> u16 unused:15-x-y; > >> > >> Not sure about the y and x. Ilpo, can you comment on those values? > > > > I don't remember top of the hat how much of nonagle used, but for > > frto_counter max value was 3 iirc. > > I think nonagle uses 4 bits: > ====== > #define TCP_NAGLE_OFF 1 /* Nagle's algo is disabled */ > #define TCP_NAGLE_CORK 2 /* Socket is corked */ > #define TCP_NAGLE_PUSH 4 /* Cork is overridden for already queued data */ > ====== > > > However, I'm unsure if compiler is > > nowadays wise enough to handle bitfields in some not all so stupid way. > > Would you then recommend to use a byte for each value, thus avoiding the > bitfields? I don't know about the current compilers but at least in past there has been a bias against bitfields. Alternative would be to combine and code the accessors manually (thus bypassing any "too clever" compiler intelligence). -- i. ---696230645-638774431-1266484965=:9961--