\subsection{Memory Alignment Nightmares}

%Sometimes, the smallest detail in the hardware architecture can turn into a permanent nightmare for the software developer, and how the IXP deals with unaligned structures in memory is one of them. It should be reminded to the reader that DRAM is organized internally in units of 64 bits, and that it is typically not possible to request the read of an individual byte from memory.
%This is something RISC programmers are used to and the presence of \texttt{ld\_field} microinstruction is often sufficient to extract proper byte(s) out of a transfer register.

%However, in the case of network programming, things quickly get wild. Indeed, what the hardware will store in DRAM is a complete L2 frame, e.g. starting with Ethernet source and destination addresses and ending after Ethernet checksum trailer. Given the size of Ethernet header, for instance, that implies that the IP source address needs to be reconstructed from two transfer registers and that 16 bytes must be retrieved to read the IP destination which happens to be split on two distinct longwords.

%Of course, if the packet was delivered over a SONET or CSIX interface rather than from Ethernet, the alignment offset is no longer the same. We thus need to compute in the classifier where in the DRAM longword the IP headers start and branch to code that can properly extract fields in that case.

%\label{crc-and-byte-align}

%Things even get more complicated with ESP (and wasp) headers where the presence of options in the IP header could make the ESP block appear virtually at any offset. The size of ESP headers has been carefully picked so that (64 bit) operands are naturally re-aligned in the base case (Ethernet frame and no options in IP headers), but this is only an optimization. The code for reading or updating operands in ESP filter thus needs to be duplicated 8 times for accomoding every possible mis-alignment.

%In WASP microblock, we chose a different approach involving a special instruction\footnote{\texttt{byte\_align}, which is especially tedious to use properly in the IXP2400 serie}, which allowed us to keep most of the code independent of the actual realignment, but at the expense of higher granularity in data transfers. Thanks to the fact that WASP packets data are multiple of 32 bytes, that higher granularity causes less troubles for us than in the ESP filter and we can still achieve good performance.

-------------------

Il y a des bouts de ma thèse, comme celui ci-dessus qui finissent intégralement en commentaires. J'avais essayé de leur donner un ton intéressant, ils témoignent d'une semaine particulièrement pénible où, alors que je croyais avoir trouvé *là* solution, le même problème bêtement technique apparaît à nouveau...

En relisant, c'est une section tout entière "So you Want to be an IXP programmer" qui se retrouve disséquée, éparpillée par-ci par-là dans les autres chapitres et des sous-sections comme celle-ci passent entièrement à la trappe: je n'arriverai pas à donner suffisamment d'info au lecteur pour qu'il puisse comprendre le dilemme ... pourtant, j'ai envie de pouvoir partager ce genre d'expérience. Vous ne comprenez rien au texte ? Bilou va vous expliquer ça mieux que moi.