From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [RFC 1/2] net: Introduce recvmmsg socket syscall Date: Wed, 20 May 2009 20:50:44 -0700 (PDT) Message-ID: <20090520.205044.185308597.davem@davemloft.net> References: <20090521004634.GB29869@localhost.localdomain> <20090521020541.GD5956@ghostprotocols.net> <20090521022621.GA2173@localhost.localdomain> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: acme@redhat.com, netdev@vger.kernel.org, vanhoof@redhat.com, williams@redhat.com To: nhorman@tuxdriver.com Return-path: Received: from 74-93-104-97-Washington.hfc.comcastbusiness.net ([74.93.104.97]:45570 "EHLO sunset.davemloft.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752465AbZEUDuq (ORCPT ); Wed, 20 May 2009 23:50:46 -0400 In-Reply-To: <20090521022621.GA2173@localhost.localdomain> Sender: netdev-owner@vger.kernel.org List-ID: From: Neil Horman Date: Wed, 20 May 2009 22:26:21 -0400 > I agree, your way of doing this definately lets you layer on top of > the existing vetted implementation, which is nice, I just thought > that avoiding the creation of another syscall might be worth a > little extra work in the kernel. Instead of arrays of msghdrs, We'd > be looking at chains like this: msghdr->(struct msghdr > *)msg_control[i].data->msghdr->etc > > Not too hard to parse, I dont think. But I'll defer to brighter > minds than mine. If the creation of another syscall isn't too > difficult a barrier to overcome (assuming this is going to occur for > sendmsg, and various other i/o ops as well), then your way here is > probably the way to go. Unfortunately you can't use msg flags for this. We accept any message flag we don't understand without signalling any errors. So there is no way to determine if the kernel supports the flag or not. Whereas with a socket option, we'll always get an error on older kernels for unsupported options. I think the system call is the cleanest, because it's not only a semantic change but also a data type change. I also think the socket option scheme is too cumbersome. I think it would be common for an application to want to use both modes of sending, especially if that application uses lots of existing library mode to compose some messages. And extra setsockopt() around every call down into that library? Yikes, good luck getting that right all the time. It's way too error prone.