From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752725AbYLSTHt (ORCPT ); Fri, 19 Dec 2008 14:07:49 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751168AbYLSTHg (ORCPT ); Fri, 19 Dec 2008 14:07:36 -0500 Received: from brick.kernel.dk ([93.163.65.50]:4944 "EHLO kernel.dk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750978AbYLSTHf (ORCPT ); Fri, 19 Dec 2008 14:07:35 -0500 Date: Fri, 19 Dec 2008 20:07:02 +0100 From: Jens Axboe To: Vladislav Bolkhovitin Cc: "David M. Lloyd" , linux-mm@kvack.org, Christoph Hellwig , James Bottomley , linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, scst-devel@lists.sourceforge.net, Bart Van Assche , netdev@vger.kernel.org Subject: Re: [RFC]: Support for zero-copy TCP transmit of user space data Message-ID: <20081219190701.GP32491@kernel.dk> References: <4941590F.3070705@vlnb.net> <1229022734.3266.67.camel@localhost.localdomain> <4942BAB8.4050007@vlnb.net> <1229110673.3262.94.camel@localhost.localdomain> <49469ADB.6010709@vlnb.net> <20081215231801.GA27168@infradead.org> <4947FA1C.2090509@vlnb.net> <494A97DD.7080503@vlnb.net> <494A99EF.6070400@flurg.com> <494BDBC5.7050701@vlnb.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <494BDBC5.7050701@vlnb.net> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 19 2008, Vladislav Bolkhovitin wrote: > David M. Lloyd, on 12/18/2008 09:43 PM wrote: > >On 12/18/2008 12:35 PM, Vladislav Bolkhovitin wrote: > >>An iSCSI target driver iSCSI-SCST was a part of the patchset > >>(http://lkml.org/lkml/2008/12/10/293). For it a nice optimization to > >>have TCP zero-copy transmit of user space data was implemented. Patch, > >>implementing this optimization was also sent in the patchset, see > >>http://lkml.org/lkml/2008/12/10/296. > > > >I'm probably ignorant of about 90% of the context here, but isn't this the > >sort of problem that was supposed to have been solved by vmsplice(2)? > > No, vmsplice can't help here. ISCSI-SCST is a kernel space driver. But, > even if it was a user space driver, vmsplice wouldn't change anything > much. It doesn't have a possibility for a user to know, when > transmission of the data finished. So, it is intended to be used as: > vmsplice() buffer -> munmap() the buffer -> mmap() new buffer -> > vmsplice() it. But on the mmap() stage kernel has to zero all the newly > mapped pages and zeroing memory isn't much faster, than copying it. > Hence, there would be no considerable performance increase. vmsplice() isn't the right choice, but splice() very well could be. You could easily use splice internally as well. The vmsplice() part sort-of applies in the sense that you want to fill pages into a pipe, which is essentially what vmsplice() does. You'd need some helper to do that. And the ack-on-xmit-done bits is something that splice-to-socket needs anyway, so I think it'd be quite a suitable choice for this. -- Jens Axboe From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by kanga.kvack.org (Postfix) with ESMTP id 92C3C6B0044 for ; Fri, 19 Dec 2008 14:05:25 -0500 (EST) Date: Fri, 19 Dec 2008 20:07:02 +0100 From: Jens Axboe Subject: Re: [RFC]: Support for zero-copy TCP transmit of user space data Message-ID: <20081219190701.GP32491@kernel.dk> References: <4941590F.3070705@vlnb.net> <1229022734.3266.67.camel@localhost.localdomain> <4942BAB8.4050007@vlnb.net> <1229110673.3262.94.camel@localhost.localdomain> <49469ADB.6010709@vlnb.net> <20081215231801.GA27168@infradead.org> <4947FA1C.2090509@vlnb.net> <494A97DD.7080503@vlnb.net> <494A99EF.6070400@flurg.com> <494BDBC5.7050701@vlnb.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <494BDBC5.7050701@vlnb.net> Sender: owner-linux-mm@kvack.org To: Vladislav Bolkhovitin Cc: "David M. Lloyd" , linux-mm@kvack.org, Christoph Hellwig , James Bottomley , linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, scst-devel@lists.sourceforge.net, Bart Van Assche , netdev@vger.kernel.org List-ID: On Fri, Dec 19 2008, Vladislav Bolkhovitin wrote: > David M. Lloyd, on 12/18/2008 09:43 PM wrote: > >On 12/18/2008 12:35 PM, Vladislav Bolkhovitin wrote: > >>An iSCSI target driver iSCSI-SCST was a part of the patchset > >>(http://lkml.org/lkml/2008/12/10/293). For it a nice optimization to > >>have TCP zero-copy transmit of user space data was implemented. Patch, > >>implementing this optimization was also sent in the patchset, see > >>http://lkml.org/lkml/2008/12/10/296. > > > >I'm probably ignorant of about 90% of the context here, but isn't this the > >sort of problem that was supposed to have been solved by vmsplice(2)? > > No, vmsplice can't help here. ISCSI-SCST is a kernel space driver. But, > even if it was a user space driver, vmsplice wouldn't change anything > much. It doesn't have a possibility for a user to know, when > transmission of the data finished. So, it is intended to be used as: > vmsplice() buffer -> munmap() the buffer -> mmap() new buffer -> > vmsplice() it. But on the mmap() stage kernel has to zero all the newly > mapped pages and zeroing memory isn't much faster, than copying it. > Hence, there would be no considerable performance increase. vmsplice() isn't the right choice, but splice() very well could be. You could easily use splice internally as well. The vmsplice() part sort-of applies in the sense that you want to fill pages into a pipe, which is essentially what vmsplice() does. You'd need some helper to do that. And the ack-on-xmit-done bits is something that splice-to-socket needs anyway, so I think it'd be quite a suitable choice for this. -- Jens Axboe -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org