SOCKMAP – TCP splicing of the future

Re:SOCKMAP – TCP splicing of the future by jandrese on Monday February 18, 2019 @12:27PM (#19192318)

This article had me all excited until they got to the benchmarks. Hopefully this is just some design deficiencies and not something terrible like running a BPF bytecode is just plain slower than a couple of context switches.

[ Parent | on HN ]

Re:SOCKMAP – TCP splicing of the future by majke on Monday February 18, 2019 @04:09PM (#19194478)

I really really wanted to prove SOCKMAP rocks. Oh, well. Not just yet. In one of the linked videos the SOCKMAP authors say they didn't optimize part of the code. So there definitely is plenty of room.

I don't see any fundamental reason why SOCKMAP wouldn't be fastest. It's just a matter of putting an effort into it.

For example, we noticed the poor splice(2) performance is due to a spinlock. We need to figure out just why this happens, but it doesn't seem like a major problem. Probably just a trivial regression.

[ Parent | on HN ]

Re:SOCKMAP – TCP splicing of the future by jandrese on Monday February 18, 2019 @04:52PM (#19194817)

I really appreciate the effort you put into doing the benchmarks. Reading the first half of your article I was excited but also slightly dreading that I'd have to go to the trouble to create and run the benchmarks to see if it was worth the effort.

[ Parent | on HN ]

Re:SOCKMAP – TCP splicing of the future by londons_explore on Tuesday February 19, 2019 @03:50AM (#19197558)

For optimising things like this I can recommend using ARM's ITM tracing.

Then you can get a view of every clock cycle and what is going on in the CPU, the caches, the hardware peripherals, the DMA controller etc.

You can start from a goal like "I want a TCP packet forwarded in under 5k clock cycles" and keep hacking code till you've met it.

Other software based tracing tools don't tend to be as good, and frequently rely on statistical techniques which hide what is really going on.

[ Parent | on HN ]