netdev - Re: [RFC 1/2] net: Introduce recvmmsg socket syscall

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090521004634.GB29869@localhost.localdomain>
Date:	Wed, 20 May 2009 20:46:34 -0400
From:	Neil Horman <nhorman@...driver.com>
To:	Arnaldo Carvalho de Melo <acme@...hat.com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	Chris Van Hoof <vanhoof@...hat.com>,
	Clark Williams <williams@...hat.com>
Subject: Re: [RFC 1/2] net: Introduce recvmmsg socket syscall

On Wed, May 20, 2009 at 08:06:52PM -0300, Arnaldo Carvalho de Melo wrote:
> Meaning receive multiple messages, reducing the number of syscalls and
> net stack entry/exit operations.
> 
> Next patches will introduce mechanisms where protocols that want to
> optimize this operation will provide an unlocked_recvmsg operation.
> 
> Signed-off-by: Arnaldo Carvalho de Melo <acme@...hat.com>
Its a neat idea, I like the possibility on saving lots of syscalls for
busy sockets, but I imagine the addition of a new syscall gives people pause.  I
wonder if simply augmenting the existing recvmsg syscall with a message flag to
indicate that multiple messages can be received on that call.

What I would propose looks something like:

1) define a new flag in the msghdr pointer for msg_flags, MSG_COMPOUND.  Setting
this on the call lets the protocol we can store multiple messages

2) if this flag is set the msg_control pointer should contain a cmsghdr with a
new type MSG_COMPOUND_NEXT, in which the size is sizeof(void *) and the data
contains a pointer to the next msghdr pointer.

3) The kernel can iteratively fill out buffers passed in through the chain,
setting the MSG_COMPOUND flag on each msghdr that contains valid data.  The
first msghdr to not have the MSG_COMPOUND flag set denotes the last buffer that
the kernel put valid data in.  This way the buffer chain pointer is kept
unchanged, and userspace can follow it to free the data if need be.

Thoughts?

Neil

> 
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html