New developer - Hello.

[James Darnley]

Hello to all.

I'm James Darnley. I was approached by Luke Gorrie about writing a
feature for you after he saw one of my posts on a Hacker News thread.
Specifically he asked about AES encryption using Intel's AES-NI set and
maybe later extending DynASM and other assembly tasks.

My experience with assembly comes from writing DSP functions for FFmpeg.
My interest in Lua developed while I was using it in a personal project.

Your Snabb Switch project sounds ambitious yet very interesting. I hope
I will be a good fit for the community and that I am able to complete
task. I'm sure I will have some specific questions in the near future
but I thought I should introduce myself first.

Until then,
James.

[Katerina Barone-Adesi]

Welcome, James! I hope you have fun hacking in this ecosystem; it's a
pretty fun one.

Kat

[Max Rottenkolber]

Hi James,

welcome on board! :) If you have *any* questions about the code base
and/or development infrastructure: go ahead and ask on the mailing list!
You can also email me directly as well.

Cheers,
max

[Luke Gorrie]

Welcome James :-)

On 27 October 2015 at 15:22, James Darnley <james....@gmail.com> wrote:

I'm James Darnley.  I was approached by Luke Gorrie about writing a
feature for you after he saw one of my posts on a Hacker News thread.
Specifically he asked about AES encryption using Intel's AES-NI set and
maybe later extending DynASM and other assembly tasks.

I owe the list a braindump about assembler hacks :-)

Snabb Switch occasionally needs to perform an operation that is "morally" assembler. I would like to start being consistent about this and having our own small library of assembler routines based on the same DynASM assembler that the LuaJIT VM is written with.

I like assembler in moderation. It is simple and direct. There is some great reference material available for the latest CPUs too e.g. Agner Fog's optimization manuals, Intel's assembler optimization, and a wonderful book called "Computer Systems: A Programmer's Perspective".

The alternative to having our own little assembler routines is to depend on third party tools and libraries and this seems a bit sub-optimal.

Examples:

Our packet copies are done with GLIBC memcpy. On paper this is nice: it's an assembler routine that somebody else has written and debugged and the exact version is selected based on the running CPU. In practice though we don't have control over whether people will have a new enough GLIBC version to suit their CPU. The current Ubuntu LTS release will be supported until the year 2019 and it lacks support for AVX2 CPUs (released 2015). The next Ubuntu LTS release will be supported until 2021 and that will probably lack support for AVX512 CPUs (to be released in 2017). So there is a real risk that in the field Snabb Switch will end up being linked with the routines for the previous CPU generation.

Our SIMD checksum routines are done using GCC intrinsics. This works but it is a bit annoying. It has caused one SIGILL crash bug where the compiler didn't generate the instruction that we expected (mustn't mix SIMD routines for different CPUs in the same C source file). Generally too I don't feel like GCC SIMD intrinsics are "simple and honest" in the same way as assembler code: rather it is yet another layer of technology that doesn't necessarily provide much benefit. (I also see the risk that we will develop undocumented dependencies on particular GCC versions if we are using bleeding edge features that may have bugs in commonly installed versions -- not an issue with LuaJIT/DynASM since we always use the exact same version.)

AES-NI is another one. I am sure we could use an Intel C library to access those instructions indirectly but that would be yet-another software dependency.

Accessing CPU performance counters is another example. In principle we could make a system call into the kernel and ask it to read the value for us but it seems neater to just execute that RDPMC instruction directly.

One more scenario is that occasionally we have wanted to understand the maximum performance that we could possible achieve for some operation. I did one experiment on that app network like this (https://github.com/SnabbCo/snabbswitch/pull/603). Once we have a 100G NIC in the lab I also expect that we will want to write some assembler code to find out whether it is possible to dispatch a full 100G traffic stream using one CPU core (or whether it is mandatory to offload this onto the RSS/VMDq features of the NIC).

So the picture that emerges is that we could satisfy all these needs in a consistent and self-sufficient way by writing and maintaining a few assembler routines with DynASM. This requires some improvements to the DynASM assembler - already done now, @corsix just added support for the AES-NI and AVX2 instruction sets (hurray!) - and it also requires the Snabb Switch community to cultivate our assembler hacking capabilities (Hi James! :-))

See also a related rant on the LuaJIT Github repo:

https://github.com/LuaJIT/LuaJIT/issues/100

End braindump on assembler :-)

Cheers!

-Luke

[Luke Gorrie]

Hi James,

It is quite fun to know that we have a real live assembler programmer on the mailing list :-). I am emboldened to braindump some of the assembler-related ideas that have been bouncing around in my head and that I am not sure whether they are fundamentally sound or crazy.

One that we have been pondering for a long time is this: Are packet copies fundamentally cheap or expensive? and why?

My theory is that they are fundamentally cheap but that we may have to do a little assembler hacking to fully realize this. I did a little write-up that people are welcome to shoot down :-)

https://github.com/SnabbCo/snabbswitch/issues/648

On 27 October 2015 at 15:22, James Darnley <james....@gmail.com> wrote:

--
You received this message because you are subscribed to the Google Groups "Snabb Switch development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to snabb-devel...@googlegroups.com.
To post to this group, send an email to snabb...@googlegroups.com.
Visit this group at http://groups.google.com/group/snabb-devel.