From mboxrd@z Thu Jan  1 00:00:00 1970
From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Subject: Re: [PATCH RFC net-next 1/6] sock: MSG_PEEK support for
 sk_error_queue
Date: Thu, 18 Jan 2018 18:03:41 -0500
Message-ID: <20180118230341.GG24553@oracle.com>
References: <cover.1516147540.git.sowmini.varadhan@oracle.com>
 <05d060dc1169649d84c37ad51b0f8fe54a2a3185.1516147540.git.sowmini.varadhan@oracle.com>
 <CAF=yD-KkL+rnSOvYMFKmeaJoD1zLj1mxtroccTNUJGrhm4SyKA@mail.gmail.com>
 <20180118110207.GA24920@oracle.com>
 <1516290887.3606.21.camel@gmail.com>
 <20180118161048.GB24553@oracle.com>
 <1516294395.3606.23.camel@gmail.com>
 <20180118171251.GD24553@oracle.com>
 <CAF=yD-Lnq6yumBn5OcpfmDoCruox=vJFyoh-N0RFrXam2HMn9g@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
        Network Development <netdev@vger.kernel.org>,
        David Miller <davem@davemloft.net>, rds-devel@oss.oracle.com,
        santosh.shilimkar@oracle.com
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from userp2120.oracle.com ([156.151.31.85]:36988 "EHLO
        userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S932379AbeARXDv (ORCPT
        <rfc822;netdev@vger.kernel.org>); Thu, 18 Jan 2018 18:03:51 -0500
Content-Disposition: inline
In-Reply-To: <CAF=yD-Lnq6yumBn5OcpfmDoCruox=vJFyoh-N0RFrXam2HMn9g@mail.gmail.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On (01/18/18 17:54), Willem de Bruijn wrote:
> > 2. If we have the option of passing completion-notification up as ancillary
> >    data on the pollin/recvmsg channel itself (instead of MSG_ERRQUEUE)
> 
> This assumes a somewhat symmetric workload, where there are enough recv
> calls to reap the notification associated with the send calls.

Your comment about the assumption is true, but at least for the database
use-cases, we have a request-response model, so the assumption works out..
I dont know if many other workloads that send large buffers have this
pattern.

> I would stay with MSG_ERRQUEUE processing. One option is to pass data
> up to userspace in the data portion of the notification skb instead of
> encoding it in ancillary data, like tcp_get_timestamping_opt_stats.

that's similar to what I have, except that it does not have the
MSG_PEEK part (you'd need to enforce that the data portion
is upper-bounded, and that the application has the responsibility
of sending down "enough" buffer with recvmsg). 

Note that any one of these choices are ok with me- I have no
special attachments to any of them.

--Sowmini