Performance of a low horsepower cpu

[tutouisreallyhappy]

Dear developer

I'm in the process of porting this to a low horsepower CPU and trying to max out at 1Gbps speed without any HW offloading. The problem I'm having is, the CPU performance is too low to reach 1Gbps speeds,

I am considering using two options to reduce CPU consumption:

• using mmap and zero cpoy to re
• merge it to kernel space

I was just wondering if you could give your opinion on these two options, or if you have a better idea. Thank you!

Thanks
happy,

[lc9892]

Well, I have spent time on this exact endeavor so I'll propose a number of things to try before going down a much more involved path. I do recommend looking at the README as well as the BEST_PRACTICES for insights that may be relevant. I don't know anything about your specific device but, as an example, it is possible to get very reliable 1G tests on a Raspberry Pi4 (the first Pi model with a true 1G Ethernet interface). Anyway, here you go...

• Compile it with full optimizations (shown in the runtime header as "Optimizations: SendMMsg()+GSO RecvMMsg()+Trunc"). Sending and receiving multiple messages at a time helps. GSO can significantly increase send rates (by reducing per-datagram protocol stack overhead) and truncation means that only the tiny PDU header is copied into the application's memory space.

• If your OS is 64-bit, compile obudpst as 64-bit. This can help a lot with some RISC processors.

• If your network supports jumbo frames (a 9000 byte MTU) end-to-end, use jumbo datagrams. This is the default unless you use the '-j' option. If your device or network does not support jumbo frames, make sure you avoid IP fragmentation by using the '-j' option. Fragmentation can kill your performance.

• If your network supports a 1500 byte MTU end-to-end (which is typical, unless using cellular) make sure you use the '-T' option to take full advantage of it. Otherwise, the maximum IP size generated (when also using '-j') is 1250 bytes. This is so it works well by default when using cellular or a tunneling protocol.

• If you have a multi-core CPU and all the network interrupts are being handled by one core (typically 0), avoid running obudpst on that core. For example, avoid core 0 via "$ taskset -c 1-3 udpst...".

• If you need or want to do multi-connection testing, check out the section in the README that begins "Before moving on, a final consideration for the Raspberry Pi 4 (because this may apply to other devices)...". It may not be applicable for your device, but it's worth checking.

• Another option is to disable UDP checksum insertion and verification. This can be done at the application layer with a small code change or for an entire interface via system commands. It becomes more tricky (or not realistic) for IPv6, because it's mandated, and exposes testing to data corruption. Overall, I don't recommend it for general use. Although, this is one of the reasons why we added a header checksum option to our PDUs (see "Optional Header Checksum and PDU Integrity Checks" in the README). In general, this is one of the optimizations typically provided by a non-standard (accelerated) network API. We can discuss more if you want.

Anyway, I hope these help and maybe allow you to avoid a bunch of work...

Len