On Thu, May 2, 2024 at 7:29 AM Éric Vyncke via Datatracker <nore...@ietf.org> wrote:
> > # COMMENTS (non-blocking) > > ## Unbalanced ? > > It has been a long time since I worked with IPsec, but I have a small > concern > about this proposal: one peer will use its own selector/SADB to select a > child > SA and the associated SPI based on *local* state (e.g., CPU utilization) > but > the selected SA/SPI may end up on the remote peer on a heavily loaded CPU. > If > this is an issue, then should it be documented somewhere in this document > (the > remote can shuffle of course the SA among its CPUs)? > CPUs might be busy but generally the CPU generating the reply packet should really be the CPU that encrypts it. Anything else causes locking. This is true even if the CPU is relatively busy. We avoided local implementation details because there are many other things to consider too, such as 4 mega CPUs running against 48 smaller CPUs. We tried to keep hardware specific things out of the specification. Hipefully the RFC has a longer livespan than the technology hacks :) > > ## Section 1 > > I am intrigued by the lack of linearity in the implementation result: 1 > CPU -> > 5 Gbps then 30 CPUs -> 60 Gbps (i.e., 2 Gbps/CPU). Some explanations would > be > appreciated + reference to the implementation itself. > It was fairly linearly for the first couple of CPUs, but locks do weird things :) > Does the amount of core per CPU have any impact ? > If you are referring to hyperthreading tricks, those are all best disabled, as it turns out that enabling hyperthreading has a strong negative impact on AESNI assisted encryption, as this capability then has to somewhat virtualized/shared, introducing locking. `PFP is also not widely implemented.` a reference would be welcome as this > statement does not appear to be based on facts (I do not dispute the > validity > of the statement). > I have no real references other than never having encountered it or seen any code for it, and having wanted it for similar reasons (an IPsec SA per flow so it gets distributed over multiple CPUs). Linux and BSDs do not support it. > # NITS (non-blocking / cosmetic) > > ## Section 4 > > s/a 1RTT delay/a 1 RTT delay/ > Fixed. Paul
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
