From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vladislav Bolkhovitin Subject: Re: [RFC]: Support for zero-copy TCP transmit of user space data Date: Fri, 19 Dec 2008 20:57:33 +0300 Message-ID: <494BE08D.30101@vlnb.net> 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> <87zlisz9pg.fsf@basil.nowhere.org> <494BDBFC.7060707@vlnb.net> <20081219180009.GP25779@one.firstfloor.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: 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 To: Andi Kleen Return-path: Received: from mout-bounce.kundenserver.de ([212.227.17.1]:57665 "EHLO mout-bounce.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751660AbYLSR5R (ORCPT ); Fri, 19 Dec 2008 12:57:17 -0500 In-Reply-To: <20081219180009.GP25779@one.firstfloor.org> Sender: netdev-owner@vger.kernel.org List-ID: Andi Kleen, on 12/19/2008 09:00 PM wrote: >> Sure, this is why I propose to disable that option by default in >> distribution kernels, so it would produce no harm. > > That would make the option useless for most users. You might as well > not bother merging then. I believe 99.(9)% of users prefer don't patch kernel, if possible. >> first, only then enable that option, then rebuild the kernel. (I'm >> repeating it to make sure you didn't miss this my point; it was in the >> part of my original message, which you cut out.) > > That was such a ridiculous suggestion, I didn't take it seriously. > > Also it should be really not rocket science to use a separate > table for this. Sorry, what do you mean? If usage of something like a hash table to map pages to the corresponding iSCSI commands, this approach was evaluated and rejected, because it wouldn't provide much performance increase, which would worth the effort. See details in the end of the patch description in http://lkml.org/lkml/2008/12/10/296 Thanks, Vlad