From patchwork Mon Oct 27 17:03:14 2008 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Evgeniy Polyakov X-Patchwork-Id: 5936 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by ozlabs.org (Postfix) with ESMTP id 5D7F6DDDEF for ; Tue, 28 Oct 2008 04:03:22 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751301AbYJ0RDR (ORCPT ); Mon, 27 Oct 2008 13:03:17 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751262AbYJ0RDR (ORCPT ); Mon, 27 Oct 2008 13:03:17 -0400 Received: from kandzendo.ru ([195.178.208.66]:38372 "EHLO tservice.net.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750866AbYJ0RDR (ORCPT ); Mon, 27 Oct 2008 13:03:17 -0400 Received: by tservice.net.ru (Postfix, from userid 1000) id 742A0FE4B; Mon, 27 Oct 2008 20:03:14 +0300 (MSK) Date: Mon, 27 Oct 2008 20:03:14 +0300 From: Evgeniy Polyakov To: Ilpo =?utf-8?B?SsOkcnZpbmVu?= Cc: David Miller , Netdev , efault@gmx.de, mingo@elte.hu, a.p.zijlstra@chello.nl, Herbert Xu Subject: Re: tbench wrt. loopback TSO Message-ID: <20081027170314.GA25148@ioremap.net> References: <20081015.171408.193701292.davem@davemloft.net> <20081026123442.GA31506@ioremap.net> <20081026.185911.193696873.davem@davemloft.net> <20081027141332.GA4691@ioremap.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, Oct 27, 2008 at 05:19:17PM +0200, Ilpo Järvinen (ilpo.jarvinen@helsinki.fi) wrote: > On Mon, 27 Oct 2008, Evgeniy Polyakov wrote: > > > On Mon, Oct 27, 2008 at 09:49:21AM +0200, Ilpo Järvinen (ilpo.jarvinen@helsinki.fi) wrote: > > > > > That's what I got with the current tree for 8 threads on a 4-way 32-bit > > > > > Xeons (2 physical CPUs) and 8gb of ram: > > > > > gso/tso off: 361.367 > > > > > tso/gso on: 354.635 > > > > > > > > Yes, it might do this, in which case tcp_tso_should_defer() simply needs > > > > some tweaking. > > > > > > Good point, could you Evgeniy verify first if simple goto send_now; in > > > beginning there recovers it all... > > > > With direct goto at the begining of the tcp_tso_should_defer() > > and 4403b406 commit git tree (was current yesterday night) > > I got following numbers: > > > > with goto: > > tso/gso on: 358.976, 357.699 > > tso/gso off: 368.016, 367.079 > > > > no goto > > tso/gso on: 353.656, 354.791 > > tso/gso off: 364.8, 365.85 > > > > So tcp_tso_should_defer() adds additional problems not counted in > > tso/gso changes. > > Noticed that tcp_current_mss does modulo with tso and that it is > being called from a non-trivial number of places, though ovbiously only > part of them should be relevant here. ...I'm not sure if that can show > up though. That's why when I see modulo something screams inside me... I used following patch (without goto in the tcp_tso_should_defer(): tso/gso on: 361.866 362.662 tso/gso off: 370.038 368.768 So this is another improvement hidden and not accounted in the tso/gso stuff. Another modulo sits in tcp_mss_split_point(). Also found one in the scheduler's find_next_best_node(), which is under CONFIG_NUMA though. diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c index e4c5ac9..8ee7597 100644 --- a/net/ipv4/tcp_output.c +++ b/net/ipv4/tcp_output.c @@ -1075,7 +1075,6 @@ unsigned int tcp_current_mss(struct sock *sk, int large_allowed) tp->tcp_header_len); xmit_size_goal = tcp_bound_to_half_wnd(tp, xmit_size_goal); - xmit_size_goal -= (xmit_size_goal % mss_now); } tp->xmit_size_goal = xmit_size_goal;