From owner-freebsd-arch@FreeBSD.ORG Tue May 27 03:28:13 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC9A737B401 for ; Tue, 27 May 2003 03:28:13 -0700 (PDT) Received: from cirb503493.alcatel.com.au (c18609.belrs1.nsw.optusnet.com.au [210.49.80.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8ACCB43F93 for ; Tue, 27 May 2003 03:28:12 -0700 (PDT) (envelope-from peterjeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])h4RASAp9044708; Tue, 27 May 2003 20:28:11 +1000 (EST) (envelope-from jeremyp@cirb503493.alcatel.com.au) Received: (from jeremyp@localhost) by cirb503493.alcatel.com.au (8.12.8/8.12.8/Submit) id h4RAS6Ub044707; Tue, 27 May 2003 20:28:06 +1000 (EST) Date: Tue, 27 May 2003 20:28:06 +1000 From: Peter Jeremy To: Igor Sysoev Message-ID: <20030527102806.GC44520@cirb503493.alcatel.com.au> References: <20030526201740.GA22178@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: arch@freebsd.org Subject: Re: sendfile(2) SF_NOPUSH flag proposal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2003 10:28:14 -0000 On Tue, May 27, 2003 at 11:57:20AM +0400, Igor Sysoev wrote: >I thought about it more and I agree with you. TF_NOPUSH should be turned on >at the start of a transaction and turned off at the end of a transaction. > >So I think there should be two flags: >SF_NOPUSH - it turns TF_NOPUSH on before the sending. It's cheap: >SF_PUSH - it turns TF_NOPUSH off after the sending has been completed. I agree that the code appears trivial but in order to justify its inclusion, you will need to demonstrate that there is some benefit to FreeBSD to implement this code. Good justification would be: 1) The same API is implemented somewhere else (or there is agreement between multiple groups to implement it). I don't believe this functionality is implemented anywhere else and you've not provided any evidence that any other groups are considering such functionality. 2) The new feature provides significant performance benefit. In this case, I believe the overhead of calling setsockopt(2) is negligible so the performance gain would be negligible. 3) The new feature provides novel functionality that cannot be achieved using the existing API (eg kqueue(2)). The functionality is already available via setsockopt(2) so this isn't applicable. At this stage, I would suggest that you need to do better than "the change is cheap" to justify adding this feature. Can you quantify the performance benefits, or provide some other justification? Peter