In February of the year 2016, we asked multiple members of the networking community by the means of several mailing lists and personal correspondence. We got 16 responses to a short series of questions.
The first section was about priorities; from five options, respondents had to assign high/medium/low priority, while keeping at least one option on low priority. They also had the option to ask for one feature as free-form text.
We then asked them which language they would be willing to use to write line-rate packet-processing software:
|#||Crash free||Liveness||Worst time||Worst energy||Spec conf.||Other||Pure C99||Safe C99||Pure C++||Safe C++||Type/Mem-safe||Managed||Any, annotated|
|4||Medium||Low||Medium||Low||Low||High: Number of memory bus access, best case of CPU cycles, see MARS for CPU x86 modeling||x|
|5||Low||High||High||Medium||Low||Medium: Conformance to a feature set (e.g. IEEE dot1.q 2011 protocols). This may be the same as your earlier question regarding your spec. It was unclear.||x||x||x|
|7||High||High||Medium||Low||Low||Medium: Check for leaks of critical resources such as mbufs.||x||x|
|8||High||Low||High||Low||High||Medium: It would be useful to prove that the code does what is supposed to do (performs the intended packet transformation), but I guess this falls in the “correctness wrt a spec” category.||x||x||x||x|
|12||High||Medium||High||Low||Low||Medium: Not necessarily a new property, but I would like to have it extended to report on worst case performance, not necessarily as measured by the number of instructions. On a modern OOO core, the number of instructions is only a part of the picture considering stalls and other threads (hw or sw).||x||x|
|16||High||Medium||Low||Medium||High||High: Responsiveness to malicious use.||x||x||x|