Re: [PATCH 1/3] net: Remove support for AIO on sockets
Christoph Hellwig <[email protected]>
| Newsgroups | org.kernel.vger.linux-api,org.kernel.vger.io-uring,org.kernel.vger.linux-crypto,org.kernel.vger.linux-doc,org.kernel.vger.linux-kernel,org.kernel.vger.linux-perf-users,org.kernel.vger.netdev |
|---|---|
| Message-ID | <[email protected]> |
On Thu, May 28, 2026 at 10:56:06AM -0600, Jens Axboe wrote: > > Where? And how do make that available to in-kernel users like > > storage protocols and network file system, which really suffer from > > the current MSG_SPLICE_PAGES semantics. > > For zero copy, on both the receive and send side. Since we have a proper > notification channel, that's what we use rather than the hack that is > the error queue. Can you point me to that notification channel? > >> , and without needing msg_kiocb or the > > > > What do you think is the downside of using a kiocb here like for > > everything else with async notifications? > > Where would the notifications go? For userspace: io_uring or the error queue for the synchronous calls. For in-kernel APIs whatever the callers wants to do by doing it from ki_complete. > You'd end up inventing something new > to propagate them to userspace then. The main aim here is to have a way to get these completions from kernelspace to get rid of the current horrors around MSG_SPLICE_PAGES. > The io_uring side does not rely on > using msg_kiocb, and iirc that part was only ever used for the crypto > stuff and largely broken. Which is why I do agree with just yanking it > out. I'm not arguing for how msg_kiocb as that is a mess. But having an explicit kiocb API like all the other async file operations would make things a lot simpler.