Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756968AbbDPI5H (ORCPT ); Thu, 16 Apr 2015 04:57:07 -0400 Received: from smtp.citrix.com ([66.165.176.89]:7550 "EHLO SMTP.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753444AbbDPI4w (ORCPT ); Thu, 16 Apr 2015 04:56:52 -0400 X-IronPort-AV: E=Sophos;i="5.11,586,1422921600"; d="scan'208";a="253692976" Message-ID: <552F7936.9070205@eu.citrix.com> Date: Thu, 16 Apr 2015 09:56:22 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Eric Dumazet CC: Jonathan Davies , "xen-devel@lists.xensource.com" , Wei Liu , Ian Campbell , "Stefano Stabellini" , netdev , Linux Kernel Mailing List , Eric Dumazet , "Paul Durrant" , Christoffer Dall , Felipe Franciosi , , David Vrabel Subject: Re: [Xen-devel] "tcp: refine TSO autosizing" causes performance regression on Xen References: <1428596218.25985.263.camel@edumazet-glaptop2.roam.corp.google.com> <1428932970.3834.4.camel@edumazet-glaptop2.roam.corp.google.com> <1429115934.7346.107.camel@edumazet-glaptop2.roam.corp.google.com> <552E9E8D.1080000@eu.citrix.com> <1429118948.7346.114.camel@edumazet-glaptop2.roam.corp.google.com> <552EA2BC.5000707@eu.citrix.com> <1429120373.7346.125.camel@edumazet-glaptop2.roam.corp.google.com> <552EA844.5010308@eu.citrix.com> <1429121979.7346.138.camel@edumazet-glaptop2.roam.corp.google.com> In-Reply-To: <1429121979.7346.138.camel@edumazet-glaptop2.roam.corp.google.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-DLP: MIA1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1330 Lines: 36 On 04/15/2015 07:19 PM, Eric Dumazet wrote: > On Wed, 2015-04-15 at 19:04 +0100, George Dunlap wrote: > >> Maybe you should stop wasting all of our time and just tell us what >> you're thinking. > > I think you make me wasting my time. > > I already gave all the hints in prior discussions. Right, and I suggested these two options: "Obviously one solution would be to allow the drivers themselves to set the tcp_limit_output_bytes, but that seems like a maintenance nightmare. "Another simple solution would be to allow drivers to indicate whether they have a high transmit latency, and have the kernel use a higher value by default when that's the case." [1] Neither of which you commented on. Instead you pointed me to a comment that only partially described what the limitations were. (I.e., it described the "two packets or 1ms", but not how they related, nor how they related to the "max of 2 64k packets outstanding" of the default tcp_limit_output_bytes setting.) -George [1] http://marc.info/?i= -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/