A lot of the socket featureset of io_uring seems available in AF_XDP https://docs.kernel.org/networking/af_xdp.html which shows lots of progress since I looked last.

To get an idea of what DPDK gives low-level access to there is the overview https://doc.dpdk.org/guides/nics/features.html and my "favorite annual terabit read" https://doc.dpdk.org/guides/nics/mlx5.html#mlx5-net-features for NVIDIA NICs. Broadcom has some fun stuff too. The first time you hit top RX speed (2x400G my latest) with only one busy core (yay DMA engines) is always a thrill.

I need to check about the af_xdp ecosystem around fragmentation/reassembly in UDP too, every time I needed something there DPDK had it, often with an offload path.

Some silly stuff in DPDK are very useful for testing too (in-memory devices).

Also I'm not clear on the virtualization story on af_xdp, with dpdk I got something working at full blast 400G in VMs with little (but finnicky) work.

I was remarking on the MI350P because I've had a hard time procuring "small" CDNAx systems (for e.g. development, experiments and lower-profile servers) and OAM seemed very niche (not if you're aiming for density and training/inference...).

I hope the MI350P fills a lower part of the spectrum and I can start massively porting CUDA stuff or at least work on HIP and ROCm and what I need to make most or some of our CUDA stuff run on AMD HW, then how make it run fast.

Same for gpudirect (more useful for scale-out or training).

Everyone is focused on AI but these are two interesting techs trickling down from the NVIDIA tree, relatively "easy" to use there, which maybe exist in AMD world but I somehow missed the docs and APIs and demos on how to use them...

I only regret not writing the obvious-but-buggy code that "forgot" or added some values and still passed proof...

Did you have a look at why3 and generating verification conditions from Rust or C code (as frama-c does) ?

It would also seem highly agent-able since verification is very modular in SPARK.

Hopefully we get: actual formal coding rules, spec rules, design rules, contribution rules, documentation and testing rules. High Integrity development processes impose that you write all this before you start and makes sure you follow your own rules.

So. I guess... welcome everyone to explicit software and systems development processes.

But at some point I just figured I was wasting so much time in there. Switched tshark and jq or good old bash/awk/grep and gnuplot, back to the command-line, then python for batteries, still using the output of tshark... and then ended writing a pcap(and ng) parser with ethernet-ip-udp/tcp and a full java IDE and never went back. I went the same meandering path with every data capture and exploration tool I had to use repeatedly.

I feel I'm not the only one having this repeated sequence of tooling improvement, hopefully there is a well named scale to describe it.