From owner-freebsd-net@freebsd.org Wed Jan 20 08:29:50 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 864F3A8896C for ; Wed, 20 Jan 2016 08:29:50 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 614321E3A for ; Wed, 20 Jan 2016 08:29:50 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 5E953A88969; Wed, 20 Jan 2016 08:29:50 +0000 (UTC) Delivered-To: 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 440DEA88968; Wed, 20 Jan 2016 08:29:50 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 C4A841E38; Wed, 20 Jan 2016 08:29:49 +0000 (UTC) (envelope-from boris.astardzhiev@gmail.com) Received: by mail-wm0-x22a.google.com with SMTP id l65so168946761wmf.1; Wed, 20 Jan 2016 00:29:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+vTDR6o5a+4Vpe7UStvzcqXSbAADfj4yw89x0DnoWgA=; b=sGAOiMjRI6vo85cKo2Kj5Lhhy6oKMdSGRZM30DGLX5wifwlwCrJ6/BxhePBuQApvNz R8lgSFMVj0+C5I6kmhN8m/1PnWcOWiwk92BZfudeSWnLyursnXFSh0iVLUQmhXbCmEGt HPpIGjt+TJHkBb9E8YB1kYWB6jFqK9XcnwtUBmdjCLYAV9DVUgFuUt7+zcDkTAYj5v5h +7wbw+BjLfWFAfKdxOucv8Pm8si6VdDhOtX+OcdC1uZ51GDwhjbWel0slMBqPkfSoclh Fxf+TBBfr9xQu8EJjsCNDOSy97Tyw9wizwqOgMtTTcU/X37FzGTkuhj8Mq8Krm1s023A fkEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+vTDR6o5a+4Vpe7UStvzcqXSbAADfj4yw89x0DnoWgA=; b=LCkaoWd21uG2ICHyMwxn0NPtIuAjNwu22BkymWa65x9ccmwyVJNReki+CwNnY9RgkG 0GdBMdRoZ7s4UdQFEjdWvAssx4ikjF3DnliZE2Z6tF1KbW1CcOA3t2gP5DKJ+PZcaj2u Yla6oWNJusaCqndqaWFwDfscoPPZytBBsCUDK1dwI8tpKJZE2t46UCm/n22NdR/U6D6/ 6/KpkVxlxJRxegoThdr+4hUWIK8W75IVOjFHcI0GJp3lLAgwWhU7JgU/5+7kZIBPD55F 4zEvusKV2erak1AtrdlYOIgQw/OHXdWALOVttq5qqemw5tQ2UUNRCeMJ64VOoYw7/ntF GkWA== X-Gm-Message-State: AG10YORiKsUqT7/oQ1+Brt8KV+D4XOAoqsDWEPX2P8dZQCyEFYjH9O7q9A3TZ09nfuFVNFpX29UsfXZxGgzwPw== MIME-Version: 1.0 X-Received: by 10.28.16.8 with SMTP id 8mr2643914wmq.77.1453278587459; Wed, 20 Jan 2016 00:29:47 -0800 (PST) Received: by 10.28.136.148 with HTTP; Wed, 20 Jan 2016 00:29:47 -0800 (PST) In-Reply-To: <20160120073154.GB3942@kib.kiev.ua> References: <20160113080349.GC72455@kib.kiev.ua> <20160116195657.GJ3942@kib.kiev.ua> <20160116202534.GK3942@kib.kiev.ua> <20160117211853.GA37847@stack.nl> <20160118044826.GS3942@kib.kiev.ua> <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> Date: Wed, 20 Jan 2016 10:29:47 +0200 Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Boris Astardzhiev To: Konstantin Belousov Cc: Jilles Tjoelker , net@freebsd.org, threads@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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: Wed, 20 Jan 2016 08:29:50 -0000 jt>> jt>> FBSDprivate_1.0 { jt>> @@ -1051,4 +1053,6 @@ FBSDprivate_1.0 { jt>> gssd_syscall; jt>> __libc_interposing_slot; jt>> __libc_sigwait; jt>> + _sendmmsg; jt>> + _recvmmsg; jt>> }; jt> jt>The _ versions need not be exported. Not exporting reduces code size and jt>improves performance. I'll fix it. jt>> diff --git a/lib/libc/sys/recv.2 b/lib/libc/sys/recv.2 jt>> index 326e7ff..81a0201 100644 jt>> --- a/lib/libc/sys/recv.2 jt>> +++ b/lib/libc/sys/recv.2 jt>> [snip] jt> jt>I think the recv.2 and send.2 man pages are long enough as they are, and jt>separate recvmmsg.3 and sendmmsg.3 pages will be clearer. This is also jt>because recvmmsg/sendmmsg can be ignored when performance is good enough jt>without them. This differs from what Konstantin thinks. md>If they are to be made separate man pages can I suggest that the md>recv/send(2) manpages be changes to at least make early reference to md>the *mmsg() calls? md> md>Purely as marketing. My perception is that awareness of the *mmsg() md>calls is rather limited. Let me know the final decision then - whether in the existing manpages or in new files. jt>The Linux version has an additional parameter struct timespec *timeout jt>(but only for recvmmsg, not for sendmmsg). Note that implementing this jt>in a Linux-compatible manner has low overhead, since Linux only checks jt>it between packets and never interrupts a wait because of this timeout jt>(source: http://man7.org/linux/man-pages/man2/recvmmsg.2.html ). That's right. Shall I try to implement the timeout part or leave it the way it is now? kb>Shouldn't i and rcvd be unsigned as well ? Shouldn't return value kb>also be unsigned ? I think i and rcvd should be unsigned whereas ret should not - after all if an error occurred we get -1. kb>> + kb>> + if (vlen > VLEN_MAX) kb>> + vlen = VLEN_MAX; kb>Why is this restriction needed ? Not needed. I'll remove it. kb>> + kb>> + rcvd = 0; kb>> + for (i = 0; i < vlen; i++) { kb>> + errno = 0; kb>> + ret = __sys_recvmsg(s, &msgvec[i].msg_hdr, flags); kb>> + if (ret < 0 || errno != 0) { kb>I do not see why do you need to clear errno before, and then do this test. kb>Just check ret == -1, in which case errno was set from the immediate syscall. kb> kb>> + if (rcvd != 0) { kb>> + /* We've received messages. Let caller know. */ kb>> + errno = 0; kb>This cleaning is not needed as well. For successfull functions returns, kb>errno value is undefined. Wouldn't I confuse apps if they check errno in the follow case - I want to receive two messages. The first __sys_recvmsg succeeds and then for the second __sys_recvmsg fails. Thus errno will be != 0 and I'm telling the app that I have received one message by returning 1 but errno will be != 0. Is this correct? Regards, Boris Astardzhiev On Wed, Jan 20, 2016 at 9:31 AM, Konstantin Belousov wrote: > On Tue, Jan 19, 2016 at 01:58:27PM +0200, Boris Astardzhiev wrote: > > +int > > +recvmmsg(int s, struct mmsghdr *msgvec, unsigned int vlen, int flags) > > +{ > > + int i, ret, rcvd; > Shouldn't i and rcvd be unsigned as well ? Shouldn't return value > also be unsigned ? > > + > > + if (vlen > VLEN_MAX) > > + vlen = VLEN_MAX; > Why is this restriction needed ? > > > + > > + rcvd = 0; > > + for (i = 0; i < vlen; i++) { > > + errno = 0; > > + ret = __sys_recvmsg(s, &msgvec[i].msg_hdr, flags); > > + if (ret < 0 || errno != 0) { > I do not see why do you need to clear errno before, and then do this test. > Just check ret == -1, in which case errno was set from the immediate > syscall. > > > + if (rcvd != 0) { > > + /* We've received messages. Let caller > know. */ > > + errno = 0; > This cleaning is not needed as well. For successfull functions returns, > errno value is undefined. > > > + return (rcvd); > > + } > > + return (-1); > > + } > > + > > + /* Save received bytes */ > > + msgvec[i].msg_len = ret; > > + > Extra empty line. > > + rcvd++; > > + } > > + > > + return (rcvd); > > +} >