[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4e582b92-2f4d-4a0d-b479-3cf4f054bb5f@kernel.dk>
Date: Fri, 21 Mar 2025 14:35:51 -0600
From: Jens Axboe <axboe@...nel.dk>
To: Joe Damato <jdamato@...tly.com>, Christoph Hellwig <hch@...radead.org>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
asml.silence@...il.com, linux-fsdevel@...r.kernel.org, edumazet@...gle.com,
pabeni@...hat.com, horms@...nel.org, linux-api@...r.kernel.org,
linux-arch@...r.kernel.org, viro@...iv.linux.org.uk, jack@...e.cz,
kuba@...nel.org, shuah@...nel.org, sdf@...ichev.me, mingo@...hat.com,
arnd@...db.de, brauner@...nel.org, akpm@...ux-foundation.org,
tglx@...utronix.de, jolsa@...nel.org, linux-kselftest@...r.kernel.org
Subject: Re: [RFC -next 00/10] Add ZC notifications to splice and sendfile
On 3/21/25 10:36 AM, Joe Damato wrote:
> On Fri, Mar 21, 2025 at 05:14:59AM -0600, Jens Axboe wrote:
>> On 3/20/25 11:56 PM, Christoph Hellwig wrote:
>>>> I don't know the entire historical context, but I presume sendmsg
>>>> did that because there was no other mechanism at the time.
>>>
>>> At least aio had been around for about 15 years at the point, but
>>> networking folks tend to be pretty insular and reinvent things.
>>
>> Yep...
>>
>>>> It seems like Jens suggested that plumbing this through for splice
>>>> was a possibility, but sounds like you disagree.
>>>
>>> Yes, very strongly.
>>
>> And that is very much not what I suggested, fwiw.
>
> Your earlier message said:
>
> If the answer is "because splice", then it would seem saner to
> plumb up those bits only. Would be much simpler too...
>
> wherein I interpreted "plumb those bits" to mean plumbing the error
> queue notifications on TX completions.
>
> My sincere apologies that I misunderstood your prior message and/or
> misconstrued what you said -- it was not clear to me what you meant.
>
> It is clear to me now, though, that adding a flag to splice as
> previously proposed and extending sendfile based on the SO_ZEROCOPY
> sock flag being set are both unacceptable solutions.
>
> If you happen to have a suggestion of some piece of code that I
> should read (other than the iouring implementation) to inform how I
> might build an RFCv2, I would appreciate the pointer.
I don't know what to point you at - you need an API that can deliver
notifications, and I'm obviously going to say that io_uring would be one
way to do that. Nothing else exists on the networking side, as far as
I'm aware.
Like Christoph said, struct kiocb is generally how the kernel passes
around async or sync IO, which comes with a completion callback for IO
that initially returns -EIOCBQUEUED, meaning the operation is started
but not yet complete. Outside of that, yeah need some delivery
mechanism, as you're generating two events per zero copy send here. You
could obviously roll your own, good luck with that, or use the existing
one.
--
Jens Axboe
Powered by blists - more mailing lists