From owner-freebsd-net@freebsd.org Thu Jan 7 18:31:16 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 4C24CA6700C for ; Thu, 7 Jan 2016 18:31:16 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CA5251E06 for ; Thu, 7 Jan 2016 18:31:15 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mail-lb0-x234.google.com with SMTP id pv2so228174448lbb.1 for ; Thu, 07 Jan 2016 10:31:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=50oKhdfKCHgPNs7K9T+r5KFkvi5/KNIMQaU9bhEdHBc=; b=0sueSVCwnOD/1+UYTvcLm8qFcbGZ/CDoj5O6QWsflXFYd/UsKmCIgDCD4o/jvTyRyE F6fRbcLA6MOFowz5EmtEK7F1by/9kYBdjDyjr2l6ORLP7QGzuVRxEklfuRCqcZ2w0SHZ sJKi5BP0Xk7z7fdpnHgcM+ttrDo+cK264iAUeh4Qbq2XdM9EVQHPujkrQUjo9j8HhWr2 s0md7+bdd/qcTli6OwT35JYx7+zeo/atwcwY0Xxjczn1bMq5+Edv+sY+hUN5AiAqMkBo XRPhdO4acmCrOVqCOzNRiHxXhW+qzC/X/G29ykxyISYgR5mdgIF9pJNPewC8IlVPjr0m Sz/A== MIME-Version: 1.0 X-Received: by 10.112.50.134 with SMTP id c6mr39138233lbo.14.1452191473609; Thu, 07 Jan 2016 10:31:13 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.13.33 with HTTP; Thu, 7 Jan 2016 10:31:13 -0800 (PST) In-Reply-To: <20160107161213.GZ3625@kib.kiev.ua> References: <20160103214720.72014.qmail@f5-external.bushwire.net> <20160104085415.GS3625@kib.kiev.ua> <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> Date: Thu, 7 Jan 2016 10:31:13 -0800 X-Google-Sender-Auth: Ykny7dAFWgJmXZpXSJleZu4FZSI Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Luigi Rizzo To: Konstantin Belousov Cc: Boris Astardzhiev , Mark Delany , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 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 18:31:16 -0000 On Thu, Jan 7, 2016 at 8:12 AM, Konstantin Belousov wrote: > On Thu, Jan 07, 2016 at 03:29:23PM +0200, Boris Astardzhiev wrote: >> >What are the reasons to go with the trivial kernel implementation >> >right now, instead of trivial and simpler libc wrapper ? I think the >> >speed would be same, but the code _much_ simpler. >> >> My initial idea was such that with the kernel approach we get closer to the >> driver itself and if it has mm optimizations we may have a benefit in >> future. >> And thus one day we won't need to redo the work scrubbing the libc-only >> implementation. > > I suspect that the actual syscall interface would be more rich than the > direct translation of the function signature into the syscall. IMO it > would be easier for you to get the pure libc implementation correct > for the first step. > > With such changes, I alway much prefer to have the hard part prototyped > before making the bound changes in the API/ABI, which in this case means > that some protocol should be enchanced to the multi-message interface. 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. 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). 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. cheers luigi -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2217533 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+-------------------------------