On Thu, Jul 30, 2020 at 10:13:57PM -0400, William Allen Simpson wrote: > The comments thus far seem to be mixed. This is a perennial topic. > We spent much time on it in PIPE/SIPP/IPv6. > > We agreed on leading for AH and trailing for ESP. > > When I wrote the KA9Q NOS code implementing Van Jacobson's packet > buffers that eventually was ported to Linux by Alan Cox, the code knew > it had an incoming Ethernet or PPP frame, and offset the head on a > 16-bit or 32-bit boundary as needed with enough space at the tail for > all trailing bytes.
On Linux, it dependes a bit on the NIC driver how that is handled. The default headroom is max(32 bytes, L1_CACHE_BYTES), space for a trailer is not reserved. > The IP header was always on a 64-bit boundary. > Hopefully, that code is still present. The default alignment of the IP header is on a 16 byte boundary. It looks like this: NET_IP_ALIGN(2) + ethernet_header(14) + IP_header(20/40) + L4_header(8) Architectures can change the 2 byte NET_IP_ALIGN if they prefer DMA alignment over IP alignment. > In modern CPUs, there's always an issue with cache lines. But for a > parallel implementation, it really isn't going to matter. The CPU > that finishes last and needs to check the ICV isn't particularly > likely to be the CPU that processed the initial header anyway. While that would be possible for some algorithms, I've never seen that a single cipher request is handled by multiple CPUs. I guess that would lead to cacheline bouncing, and for GCM an atomic synchronization of the counter would be needed. Usually parallelization is achieved by using AVX registers/instructions where multiple cipher blocks can be handled simultaneously with a single instruction. So it might make sense to have the ICV at the end because it is likely cache hot when needed. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
