On 3/21/25 07:55, Stefan Metzmacher wrote:

Am 20.03.25 um 11:46 schrieb Pavel Begunkov:

quoted

On 3/19/25 19:15, Stefan Metzmacher wrote:

quoted

Am 19.03.25 um 19:37 schrieb Jens Axboe:

quoted

On 3/19/25 11:45 AM, Joe Damato wrote:

quoted

On Wed, Mar 19, 2025 at 11:20:50AM -0600, Jens Axboe wrote:

...

quoted

quoted

My argument would be the same as for other features - if you can do it
simpler this other way, why not consider that? The end result would be
the same, you can do fast sendfile() with sane buffer reuse. But the
kernel side would be simpler, which is always a kernel main goal for
those of us that have to maintain it.

Just adding sendfile2() works in the sense that it's an easier drop in
replacement for an app, though the error queue side does mean it needs
to change anyway - it's not just replacing one syscall with another. And
if we want to be lazy, sure that's fine. I just don't think it's the
best way to do it when we literally have a mechanism that's designed for
this and works with reuse already with normal send zc (and receive side
too, in the next kernel).

A few month (or even years) back, Pavel came up with an idea
to implement some kind of splice into a fixed buffer, if that
would be implemented I guess it would help me in Samba too.
My first usage was on the receive side (from the network).

I did it as a testing ground for infra needed for ublk zerocopy,
but if that's of interest I can resurrect the patches and see
where it goes, especially since the aforementioned infra just got
queued.

Would be great!

Have you posted the work in progress somewhere?

Nope apart from a dirty hack I believe I posted back then.

-- 
Pavel Begunkov