From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759855AbZAHVz2 (ORCPT ); Thu, 8 Jan 2009 16:55:28 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753205AbZAHVzO (ORCPT ); Thu, 8 Jan 2009 16:55:14 -0500 Received: from 74-93-104-97-Washington.hfc.comcastbusiness.net ([74.93.104.97]:54409 "EHLO sunset.davemloft.net" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1752100AbZAHVzN (ORCPT ); Thu, 8 Jan 2009 16:55:13 -0500 Date: Thu, 08 Jan 2009 13:55:15 -0800 (PST) Message-Id: <20090108.135515.85489589.davem@davemloft.net> To: ben@zeus.com Cc: w@1wt.eu, jarkao2@gmail.com, mingo@elte.hu, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, jens.axboe@oracle.com Subject: Re: [PATCH] tcp: splice as many packets as possible at once From: David Miller In-Reply-To: <49667534.5060501@zeus.com> References: <20090108173028.GA22531@1wt.eu> <49667534.5060501@zeus.com> X-Mailer: Mew version 6.1 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Ben Mansell Date: Thu, 08 Jan 2009 21:50:44 +0000 > > From fafe76713523c8e9767805cfdc7b73323d7bf180 Mon Sep 17 00:00:00 2001 > > From: Willy Tarreau > > Date: Thu, 8 Jan 2009 17:10:13 +0100 > > Subject: [PATCH] tcp: splice as many packets as possible at once > > Currently, in non-blocking mode, tcp_splice_read() returns after > > splicing one segment regardless of the len argument. This results > > in low performance and very high overhead due to syscall rate when > > splicing from interfaces which do not support LRO. > > The fix simply consists in not breaking out of the loop after the > > first read. That way, we can read up to the size requested by the > > caller and still return when there is no data left. > > Performance has significantly improved with this fix, with the > > number of calls to splice() divided by about 20, and CPU usage > > dropped from 100% to 75%. > > > > I get similar results with my testing here. Benchmarking an application with this patch shows that more than one packet is being splice()d in at once, as a result I see a doubling in throughput. > > Tested-by: Ben Mansell I'm not applying this until someone explains to me why we should remove this test from the splice receive but keep it in the tcp_recvmsg() code where it has been essentially forever.