[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANn89iLZAEYTpZNhGnDUfVyGXQtciZwY_aJ3xTVh=A+R5fXnqQ@mail.gmail.com>
Date: Thu, 15 Feb 2024 10:15:08 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: David Gibson <david@...son.dropbear.id.au>
Cc: Paolo Abeni <pabeni@...hat.com>, kuba@...nel.org, passt-dev@...st.top,
sbrivio@...hat.com, lvivier@...hat.com, dgibson@...hat.com, jmaloy@...hat.com,
netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: [PATCH v3] tcp: add support for SO_PEEK_OFF
On Thu, Feb 15, 2024 at 4:21 AM David Gibson
<david@...son.dropbear.id.au> wrote:
> Btw, Eric,
>
> If you're concerned about the extra access added to the "regular" TCP
> path, would you be happier with the original approach Jon proposed:
> that allowed a user to essentially supply an offset to an individial
> MSG_PEEK recvmsg() by inserting a dummy entry as msg_iov[0] with a
> NULL pointer and length to skip.
>
> It did the job for us, although I admit it's a little ugly, which I
> presume is why Paolo suggested we investigate SO_PEEK_OFF instead. I
> think the SO_PEEK_OFF approach is more elegant, but maybe the
> performance impact outweighs that.
>
Sorry, this was too ugly.
SO_PEEK_OFF is way better/standard, we have to polish the
implementation so that it is zero-cost for 99.9999 % of the users not
using MSG_PEEK..
Powered by blists - more mailing lists