From owner-freebsd-net@freebsd.org Thu Jan 7 19:28:47 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70810A66550 for ; Thu, 7 Jan 2016 19:28:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1712214D9 for ; Thu, 7 Jan 2016 19:28:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u07JSg1x025056 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 7 Jan 2016 21:28:42 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u07JSg1x025056 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u07JSesd025055; Thu, 7 Jan 2016 21:28:40 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 7 Jan 2016 21:28:40 +0200 From: Konstantin Belousov To: Luigi Rizzo Cc: Boris Astardzhiev , Mark Delany , "freebsd-net@freebsd.org" Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? Message-ID: <20160107192840.GF3625@kib.kiev.ua> References: <20160104091108.50654.qmail@f5-external.bushwire.net> <20160104093859.GV3625@kib.kiev.ua> <20160104101747.58347.qmail@f5-external.bushwire.net> <20160104194044.GD3625@kib.kiev.ua> <20160104210741.32812.qmail@f5-external.bushwire.net> <20160107161213.GZ3625@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 19:28:47 -0000 On Thu, Jan 07, 2016 at 10:31:13AM -0800, Luigi Rizzo wrote: > While it was good to have the first patch as a reminder of what needs to be done > (noticeably, discuss the various pieces to be modified and how to deal > with errors and the comments about DoS and malloc), I think that at > the moment it is premature to implement either the library functions > or the syscalls. > > What we need first is experimental data that shows a performance benefit > compared to looping around the single-packet syscall. Then we can decide > how to proceed. This is about performance. > > Implementing the library function now is relatively pointless: its only use > would be to compile some software that requires *mmsg() , and we can address > that with a custom patch for the application (which almost surely would > need to work around another ton of linux-specific functions). And this is about compatibility. I agree with the statement above about the work with the performance motivation, but I do not agree that we should not ensure compatibility because there is more to do. We have willing contributor, who learns, and who is on track to provide a usable implementation for the compat shims, be it in userspace or kernel (I do prefer userspace implementation). I do not understand you point that we can patch application. IMO it is not a useful or scalable approach to handle changing app expectations from the base platform. > > Implementing the syscall that just reflects the libc function, as Kostantin > rightly commented, may be too limited, and we cannot tell until we know > what solution permits achieving decent performance improvements, > especially on the send side -- e.g. some argument to tell the syscall > "there are more packets coming down so please hold on a bit". > For receive, there is probably very little room for enhancements, > the best we can do is grab everything from the socket. Yes, this is an argument for two things: to make libc wrapper, and to measure kernel variant, as an option.