From owner-freebsd-net@freebsd.org Thu Jan 7 19:46:38 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 6DFE9A66DEA for ; Thu, 7 Jan 2016 19:46:38 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (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 0C74215E5 for ; Thu, 7 Jan 2016 19:46:37 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mail-lf0-x22e.google.com with SMTP id c192so162728362lfe.2 for ; Thu, 07 Jan 2016 11:46:37 -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=GBsdg0ZcSVolHiZCxs6XxsTcw4n+O5MqDjpWDQkL3EU=; b=jN1KfVzM5FH3ElrcfzFdfzBGMUnpavjq8MDUtZAxb4TMg3mTb6VxZIbXXb5Gig7Ghl udipw9hYcyjBqKkoPb2sj26zkun+p0T5cX4/hMou5V+IpV5X8FL+DQklzFr2vlVtVX5t U4LvdPpcPEoEdNz8MRrig3meOt1yuUGx9fNBpEKmEtuI9CGMqPAQbt/rFLlJxKRn1XIT 77oEpL30uf8nCCLQ1O6Yt0gQ0rGjTgX4oPriVqTzwJ1DMnwr/D+KxCK/rAFJEtLMso0/ Mw17XTHv0tLkkIPVFP8ik4yTvnrjp7iymAq20r5wG3lEb9I278iv7dlY7O2o9p/ZXmPJ llIQ== MIME-Version: 1.0 X-Received: by 10.25.89.193 with SMTP id n184mr39463095lfb.28.1452195996130; Thu, 07 Jan 2016 11:46:36 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.13.33 with HTTP; Thu, 7 Jan 2016 11:46:35 -0800 (PST) In-Reply-To: <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> <20160107192840.GF3625@kib.kiev.ua> Date: Thu, 7 Jan 2016 11:46:35 -0800 X-Google-Sender-Auth: whEZFnuQb6rfNxrFgu-wVxZIhiY 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 19:46:38 -0000 On Thu, Jan 7, 2016 at 11:28 AM, Konstantin Belousov wrote: > 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. The libc API obviously needs to be conforming to the existing sendmmsg/recvmmsg. I thought your point was that the underlying syscall might possibly need a different set of parameters, so we could as well experiment a bit to see what is needed before freezing it. Regarding patching the application(s): of course it is not scalable if there are many applications that will refuse to compile if the *mmsg() functions are absent. However I expect this set of application to be minuscule if not empty, and if they exist they are probably plagued by other portability issues. So (and using *mmsg() vs *msg() is about performance) I think that until we have an underlying performant implementation of the *mmsg() calls, there is no urgency in implementing the libc functions, because we might later have to change then libc->syscall wrapper anyways. cheers luigi