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. th-cam.com/video/06qrssJ2RQs/w-d-xo.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.
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.
How mounting works internally. Like mount same volume to multiple containers
Is it something similar to DMA of Windows? It looks kinda similar to me.
Love this stuff .. 👍👍
Well presented. Thank you.
Love the low level stuff
Thank you for sharing.
What data will be in the header, and if we need to access that info, will it be another read?
another banger
Can't wait for this to hit the server kernels in 10 years.
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.
th-cam.com/video/06qrssJ2RQs/w-d-xo.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.
I just loved the Low Level Stuff... I just HATE so much abstractions...
Nice thumbnail :^)
haha 2:01
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.