luci-mod-status: 29_ports.js: improve speed formatting

[jonasjelonek]

• This PR is not from my main or master branch 💩, but a separate branch ✅
• Each commit has a valid ✒️ Signed-off-by: <my@email.address> row (via git commit --signoff)
• Each commit and PR title has a valid 📝 <package name>: title first line subject for packages
• Incremented 🆙 any PKG_VERSION in the Makefile
• Tested on: x86 (Mellanox Spectrum SN3700), OpenWrt snapshot, Safari 18.1.1 ✅
• ( Preferred ) Mention: @ the original code author for feedback
• ( Preferred ) Screenshot or mp4 of changes:
• Description:

This adds more cases for a few link speeds beyond 40 GbE, i.e. for 50 GbE, 100 GbE and 200 GbE in speed formatting for luci-mod-status. While there are currently only a few devices where this may be useful, we actually operate some 200G switches and x86 devices with 200G/100G NICs.

required to bump PKG_VERSION ?

[systemcrash]

Good idea. Perhaps we can exclude all those extra cases and make the switch case smarter and default to

		default:     e.innerText = '%d\u202fGbE%s'.format(speed/1000, d);

[systemcrash]

Not sure what will happen at 1TBit. Maybe something smarter like
case( (speed/1000000) >= 1 ): ...

[jonasjelonek]

Sure, this would just add up in the future ... so does something like this make sense? (will test it then):

switch (true) {
case (speed < 1000):     e.innerText = '%d\u202fM'.format(speed) + d; break;
case (speed == 1000):    e.innerText = '1\u202fGbE' + d; break;
case (speed > 1000000):  e.innerText = '%d\u202fTbE'.format(speed); break;
default:                 e.innerText = '%d\u202fGbE'.format(speed); break; 
}

Not sure if there are other corner cases which need to be caught ...

[systemcrash]

Sure, this would just add up in the future ... so does something like this make sense? (will test it then):

Yeah, something like that. You'll need to speed/1000000 in the format portion for Tbit ranges. Maybe even add Pbit so we can leave this code alone for a while :)

[jonasjelonek]

okay, changed it. Hopefully got everything correct ;)

EDIT: lines got quite long so added a few newlines

[systemcrash]

Yeah, sweet. Did you give it a spin on your monster NICs?

[jonasjelonek]

Yep, tested this on various devices and verified it's working for 100M, 1G, 2.5G, 10G, 25G and 100G

Sadly nothing to test with Tbit/s or Pbit/s ;)

[systemcrash]

Sadly nothing to test with Tbit/s or Pbit/s ;)

Aggregate :D

[systemcrash]

Hmm. So 2.5Gb prints as so? We don't need to change %d (int) to %f or so?

[jonasjelonek]

Ohh sorry, you're right ... prints as 2 GbE

[jonasjelonek]

probably change that for PbE and TbE too?
Not sure what speeds we can expect there, but using %f works in both cases

[systemcrash]

I wasn't certain whether %f would print a bunch of trailing zeros. If it works as-is, it can probably stay that way.

[systemcrash]

BTW did you have to build your own image, or is x86(_64?) generic good enough for the Mellanox platform?

[jonasjelonek]

I wasn't certain whether %f would print a bunch of trailing zeros. If it works as-is, it can probably stay that way.

Changed GbE, TbE and PbE to %f, no trailing zeros seen for any speeds.

BTW did you have to build your own image, or is x86(_64?) generic good enough for the Mellanox platform?

x86_64 plus some kmod driver/firmware packages are needed. Luckily there's just an Intel CPU in these switches. There's already a wiki pages describing that https://openwrt.org/toh/mellanox/spectrum

[systemcrash]

Great. Tested. Thanks @jonasjelonek