[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOi1vP-ogmcKE3brjEsm+zLvcXJa_5tGjv_XMsrnZuZUhXonhQ@mail.gmail.com>
Date: Tue, 27 Jun 2023 18:08:19 +0200
From: Ilya Dryomov <idryomov@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: David Howells <dhowells@...hat.com>, netdev@...r.kernel.org,
Xiubo Li <xiubli@...hat.com>, Jeff Layton <jlayton@...nel.org>,
"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Paolo Abeni <pabeni@...hat.com>, Jens Axboe <axboe@...nel.dk>,
Matthew Wilcox <willy@...radead.org>, ceph-devel@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v3] libceph: Partially revert changes to support MSG_SPLICE_PAGES
On Tue, Jun 27, 2023 at 5:59 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Tue, 27 Jun 2023 14:49:48 +0100 David Howells wrote:
> > Fix the mishandling of MSG_DONTWAIT and also reinstates the per-page
> > checking of the source pages (which might have come from a DIO write by
> > userspace) by partially reverting the changes to support MSG_SPLICE_PAGES
> > and doing things a little differently. In messenger_v1:
> >
> > (1) The ceph_tcp_sendpage() is resurrected and the callers reverted to use
> > that.
> >
> > (2) The callers now pass MSG_MORE unconditionally. Previously, they were
> > passing in MSG_MORE|MSG_SENDPAGE_NOTLAST and then degrading that to
> > just MSG_MORE on the last call to ->sendpage().
> >
> > (3) Make ceph_tcp_sendpage() a wrapper around sendmsg() rather than
> > sendpage(), setting MSG_SPLICE_PAGES if sendpage_ok() returns true on
> > the page.
> >
> > In messenger_v2:
> >
> > (4) Bring back do_try_sendpage() and make the callers use that.
> >
> > (5) Make do_try_sendpage() use sendmsg() for both cases and set
> > MSG_SPLICE_PAGES if sendpage_ok() is set.
> >
> > Fixes: 40a8c17aa770 ("ceph: Use sendmsg(MSG_SPLICE_PAGES) rather than sendpage")
> > Fixes: fa094ccae1e7 ("ceph: Use sendmsg(MSG_SPLICE_PAGES) rather than sendpage()")
> > Reported-by: Ilya Dryomov <idryomov@...il.com>
>
> Ilya, would you be okay if we sent the 6.5 PR without this and then
> we can either follow up with a PR in a few days or you can take this
> via your tree?
>
> Or you could review it now, that'd also work :)
>
> In hindsight we should have pushed harder to make the FS changes as
> small as possible for sendpage removal, so that they can go in via
> the appropriate tree with an appropriate level of scrutiny for 6.6,
> lesson learned :(
Hi Jakub,
This patch looks good to me. I have been meaning to actually test
it, but, if time is of the essence, I'm OK with it being merged via
the networking tree now.
Reviewed-by: Ilya Dryomov <idryomov@...il.com>
Thanks,
Ilya
Powered by blists - more mailing lists