On 7/31/20 4:32 AM, Steffen Klassert wrote:
Architectures can change the 2 byte NET_IP_ALIGN if they prefer DMA alignment over IP alignment.
As I mentioned in an earlier email, my most recent RFC work is RDMA.
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.
Currently, one CPU cannot keep up with encryption/decryption of RDMA at merely 10 Gbps, let alone 100 Gbps. This changes over time. In the beginning, we were struggling to keep up with 56 Kbps, and upgrading the backbone from 1.5 Mbps T1 to 54 Mbps T3. Then for while, CPUs outran network speeds. Now we're back again to link speeds outpacing CPUs. As I'd written PPP over SONET/SDH in 1992 (RFC 1619 published in 1994), when designing ESP circa 1992-1993 we were cognizant that link speeds would increase. After all, I'd specified the minimum speed as 156 Mbps, and up to 2.5 Gbps. There were only a few places in the world that could support those speeds, but we anticipated them. Photuris was able to run on the Intel 186 (admittedly, it took about 3 seconds), but Rivest estimated it would handle DoS attacks up to 4 Tbps.
Usually parallelization is achieved by using AVX registers/instructions where multiple cipher blocks can be handled simultaneously with a single instruction.
I'm also personally less interested in AES-GCM than ChaCha20-Poly1305. We really need to design for at least 2 algorithms. In the beginning, we worried about designing for unknown future algorithms. That's why it had very flexible transforms.
So it might make sense to have the ICV at the end because it is likely cache hot when needed.
But after removing padding for these stream algorithms, then the ICV is very likely not aligned. For zero-copy RDMA, it is rather inconvenient. And the IP header cache lines are likely still hot. Anyway, that's why I'd like to consider at least a negotiated option -- as long as it's possible to implement efficiently in Linux and others. We need to hear from more implementers. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
