Awesome videos as always thanks a lot. Are they using io_uring to copy the data from kernel space to the user space? In an io_uring you have a submit queue event and completion queue event. Normally you put data in sqe and once the kernel processes it you get the response from cqe. I think here it might be nic driver code might submit sqe to kernel and kernel will put the results in userspace but maintain the pointer to it in cqe that can be requested by the application. It's my wild guess though. It is interesting how these developments will affect the tech space, especially dpdk space but I am sure we are not yet there to completely discard dpdk since the kernel still introduces a lot of latency.
I would direct you to a pair of projects that have gone through this journey previously: DPDK & VPP - using low level driver hooks to skip relaying packet contents through the kernel. ruclips.net/video/06qrssJ2RQs/видео.html These projects have been around for almost a decade, hopefully the proposed change provides a standardized zero-copy integration with more historically normal linux networking intrinsics. Using VPP and dedicating an entire core to polling the device from user space, seems crude and wasteful when compared with a kernel packet notification scheme that this patch is attempting to implement.
They are trying to find every possible spit of performance improvement but unfortunately this is no longer in the context of ordinary computing and quantum computing is much more effort worthy now and on
Quantum computing as been improving leaps and bounds on terms of ability and usability. Not in cost or size. Even if we had functionally useful quantum computing right now we'd still be decades away from consumer quantum. There's still plenty of reason to improve non-quantum programs.
5:41 RSS in this case does not stand for memory, it stands for receive side scaling
Awesome videos as always thanks a lot.
Are they using io_uring to copy the data from kernel space to the user space?
In an io_uring you have a submit queue event and completion queue event. Normally you put data in sqe and once the kernel processes it you get the response from cqe. I think here it might be nic driver code might submit sqe to kernel and kernel will put the results in userspace but maintain the pointer to it in cqe that can be requested by the application. It's my wild guess though.
It is interesting how these developments will affect the tech space, especially dpdk space but I am sure we are not yet there to completely discard dpdk since the kernel still introduces a lot of latency.
Love this stuff .. 👍👍
Love the low level stuff
Amazing share
15:48 TCP header/data split requires NIC hardware support, which can be queried with ethtool -g
Can't wait for this to hit the server kernels in 10 years.
Well presented. Thank you.
Thank you for sharing.
another banger
I would direct you to a pair of projects that have gone through this journey previously: DPDK & VPP - using low level driver hooks to skip relaying packet contents through the kernel.
ruclips.net/video/06qrssJ2RQs/видео.html
These projects have been around for almost a decade, hopefully the proposed change provides a standardized zero-copy integration with more historically normal linux networking intrinsics. Using VPP and dedicating an entire core to polling the device from user space, seems crude and wasteful when compared with a kernel packet notification scheme that this patch is attempting to implement.
Nice thumbnail :^)
How mounting works internally. Like mount same volume to multiple containers
What data will be in the header, and if we need to access that info, will it be another read?
Is it something similar to DMA of Windows? It looks kinda similar to me.
haha 2:01
I just loved the Low Level Stuff... I just HATE so much abstractions...
They are trying to find every possible spit of performance improvement but unfortunately this is no longer in the context of ordinary computing and quantum computing is much more effort worthy now and on
Quantum computing as been improving leaps and bounds on terms of ability and usability. Not in cost or size. Even if we had functionally useful quantum computing right now we'd still be decades away from consumer quantum. There's still plenty of reason to improve non-quantum programs.