"python isn't a programming language for real men", they say. "you can't write high-quality device drivers in python", they say. "garbage collection is a problem", they say. "drivers in userspace won't be as performant as kernel ones", they say
fuck you i will use asyncio python and crimes to develop every driver in userspace and get the performance profile of a kernel driver anyway
i wonder how much UDP spam can my driver actually take. obviously most of it will never reach the NIC, but i wonder at what point will the python process break
for some reason it pegs a core basically regardless of the actual pps value, so that's not representative, and i shall test it with higher values until it breaks
the most my Python NIC could take in the transmit queue is 5.5 Gbps. it promptly drops most of it because at that point, the USB OUT tasks are rather starved and the NIC doesn't get properly serviced, but it does get all of those packets into the Python process and queues them
that's 454000 pps; about half a million syscalls in a single ordinary CPython process
i actually consider these results rather insufficient. yes, i can get CPython to accept 0.5Mpps, but it really struggles, and if I want it to concurrently handle complex USB flow control it doesn't exactly shine
I want it to be much, much better. I want it to be better than the worse USB NICs on market with their own kernel driver. it should be at least on par with CDC EEM
the USB handling is a particular source of pain right now, because realistically you want to have a zero-copy (within Python. Linux will do copy_from_user and copy_to_user, unavoidably without io_uring) implementation which takes buffers from the tap interface and puts them directly to USB
i'm doing something close to it, but not close enough
@whitequark Wow I missed the context for the other thing, and wow what a journey from the cable to ping, that's amazing. I didn't think an ice40 was big enough to have fun, clearly I need to work on my imagination!
Add comment