On Thu, Feb 9, 2023 at 10:19 PM Dave Chinner <david@xxxxxxxxxxxxx> wrote:
>
> Splice has two sides - a source where we splice to the transport
> pipe, then a destination where we splice pages from the transport
> pipe. For better or worse, time in the transport pipe is unbounded,
> but that does not mean the srouce or destination have unbound
> processing times.
Well, they are possibly fairly unbounded too - think things like
network packet re-send timeouts etc.
So the data lifetime - even just on just one side - can _easily_ be
"multiple seconds" even when things are normal, and if you have actual
network connectivity issues we are easily talking minutes.
So I don't think a scheme based on locking works even for just the
"one side" operations - at least in the general case.
That said, I wasn't really serious about my "retry" model either.
Maybe it could be made to work, but it sounds messy.
And when it comes to networking, in general things like TCP checksums
etc should be ok even with data that isn't stable. When doing things
by hand, networking should always use the "copy-and-checksum"
functions that do the checksum while copying (so even if the source
data changes, the checksum is going to be the checksum for the data
that was copied).
And in many (most?) smarter network cards, the card itself does the
checksum, again on the data as it is transferred from memory.
So it's not like "networking needs a stable source" is some really
_fundamental_ requirement for things like that to work.
But it may well be that we have situations where some network driver
does the checksumming separately from then copying the data.
Linus
