Dear developer.
Do you know the splice() feature in Linux?
http://man7.org/linux/man-pages/man2/splice.2.html
http://ogris.de/howtos/splice.html
How about to add it 
BR Aleks
On Tuesday 08 December 2015 20:50:47 Aleksandar L. wrote:
Dear developer.
Do you know the splice() feature in Linux?
Two new system calls: splice() and sync_file_range() [LWN.net]
splice(2) - Linux manual page
splice() on LinuxHow about to add it
[…]
Of course we know about splice(). You can find some mentions of it
in the mailing list archive since 2006.
The problem with this syscall is that it’s not easy to implement,
while the performance benefits are questionable (AFAIK not all network
cards work well with splice()) and use cases are limited.
It only can be useful for proxying big amounts of data without any
processing. But if you need compression, or TLS, or SSI, or even some
simple substitution, then splice() cannot be used.
wbr, Valentin V. Bartenev
Dear Valentin.
Am 09-12-2015 12:54, schrieb Valentin V. Bartenev:
processing. But if you need compression, or TLS, or SSI, or even some
simple substitution, then splice() cannot be used.
Thanks for answer.
BR Aleks
On 12/9/15 2:54 PM, Valentin V. Bartenev wrote:
processing. But if you need compression, or TLS, or SSI, or even some
simple substitution, then splice() cannot be used.
It should fit in our stream quite nicely.
–
Maxim K.
Hello!
On Thu, Dec 10, 2015 at 01:15:27AM +0300, Maxim K. wrote:
How about to add it
It only can be useful for proxying big amounts of data without any
processing. But if you need compression, or TLS, or SSI, or even some
simple substitution, then splice() cannot be used.It should fit in our stream quite nicely.
Not really, as stream is able to do SSL encoding and decoding.
–
Maxim D.
http://nginx.org/
Hello!
On Thu, Dec 10, 2015 at 03:31:23PM +0100, Lukas T. wrote:
It only can be useful for proxying big amounts of data without any
processing. But if you need compression, or TLS, or SSI, or even some
simple substitution, then splice() cannot be used.It should fit in our stream quite nicely.
Not really, as stream is able to do SSL encoding and decoding.
We also have sendfile() in nginx despite the fact that it can’t be used
in every single occasion, such as TLS sessions or when gzipping.
For sure it can be handled like sendfile(), and only used when
possible. I’m just saying that even with the stream module the
question is still the same as outlined by Valentin - questionable
potential benefits vs. added complexity.
–
Maxim D.
http://nginx.org/
Hi Maxim,
It only can be useful for proxying big amounts of data without any
processing. But if you need compression, or TLS, or SSI, or even some
simple substitution, then splice() cannot be used.It should fit in our stream quite nicely.
Not really, as stream is able to do SSL encoding and decoding.
We also have sendfile() in nginx despite the fact that it can’t be used
in every single occasion, such as TLS sessions or when gzipping.
I am aware that sendfile() is extremely useful in some configurations,
I’m
just saying the fact that it isn’t able to work with TLS wasn’t
showstopper
for it, so at the very least it shouldn’t be the only showstopper for
splice().
splice() would do something similar than sendfile(). HAProxy doesn’t
always
splice() either, but when it makes sense [1].
Regarding TLS:
There are some efforts in both linux [2] and FreeBSD [3] to implement
TLS in-kernel; leveraging kernel features like sendfile() while sending
it through a in-kernel crypto stack.
I’m not saying splice() is a must-have; I certainly don’t need it
personally, but there are use-cases out there.
Regards,
Lukas
[1]
http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#4.2-option%20splice-auto
[2] TLS in the kernel [LWN.net]
[3] https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf