From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [PATCH RFC net-next 1/6] sock: MSG_PEEK support for sk_error_queue Date: Thu, 18 Jan 2018 08:53:15 -0800 Message-ID: <1516294395.3606.23.camel@gmail.com> References: <05d060dc1169649d84c37ad51b0f8fe54a2a3185.1516147540.git.sowmini.varadhan@oracle.com> <20180118110207.GA24920@oracle.com> <1516290887.3606.21.camel@gmail.com> <20180118161048.GB24553@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Willem de Bruijn , Network Development , David Miller , rds-devel@oss.oracle.com, santosh.shilimkar@oracle.com To: Sowmini Varadhan Return-path: Received: from mail-pg0-f67.google.com ([74.125.83.67]:39410 "EHLO mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932066AbeARQxR (ORCPT ); Thu, 18 Jan 2018 11:53:17 -0500 Received: by mail-pg0-f67.google.com with SMTP id w17so8902550pgv.6 for ; Thu, 18 Jan 2018 08:53:16 -0800 (PST) In-Reply-To: <20180118161048.GB24553@oracle.com> Sender: netdev-owner@vger.kernel.org List-ID: On Thu, 2018-01-18 at 11:10 -0500, Sowmini Varadhan wrote: > On (01/18/18 07:54), Eric Dumazet wrote: > > > > Some applications out there would break horribly, trust me. > > > > so I'm not particularly attached to that solution, and I appreciate > the wisdom (and the NACK), but lets try to find a useful alternative > > The current zcopy completion notification mechanism involves syscall > overhead already, and is also inadequate for threaded applications sharing > an fd. Plus it wont work for datagram sockets. > > I'm fine with Willem's suggestion of passing a fixed number of cookies > as ancillary data (with CTRUNC to denote inadequate buffer) but if we > are really so thrifty about syscall overhead, we should not be using > sk_error_queue in the first place- perhaps we can pass up the completion > notification as ancillary data with recvmsg() on the POLLIN channel > itself (which is weird if there is no data to recv, and only ancillary > info to pass up, but hey, we are "performant"!). The thing is : MSG_PEEK 'support' will also need SO_PEEK_OFF support. And begins the crazy stuff. So lets properly design things, and not re-use legacy stuff that is proven to be not multi-thread ready and too complex. If you want to design a new channel of communication, do it, and maintain it.