Hi, On Tue, Oct 11, 2022 at 07:14:32PM +0300, Valery Smyslov wrote: > Hi Michael, > > > Valery Smyslov <smyslov.i...@gmail.com> wrote: > > > My main problem with the draft is the concept of "Fallback SA". This > > SA > > > is treated specially in the draft, which I don't think is > > > necessary. For example, it must always be up so that the outgoing > > > packet can always be sent in case per-CPU SA does not exist. Why other > > > existing per-CPU SAs cannot be used for this purpose? > > > > Because the point of the per-CPU CAs is that they are local to the CPU and > > so > > they do not require locks to acces/update. > > True. > > > I could guess that the fallback SA *does* require locks. > > It also seems to me. So I see no difference if the packet > can be re-steered to a different CPU, in any case we'll have > performance penalty.
The fallback SA needs locking, as it can be used from any cpu. But with the current approch, this is the only one that needs locking. If you try to re-steer packets to a different cpu, you need to do lookups in the SAD from remote cpus to find a cpu that has a SA that can process the packet, what in turn would require to lock per percpu databases too. > > > > affinity). There also is some mechanism that deterministically > > > dispatches incoming ESP packets to CPUs based on some information from > > > the packets, most probably from the content of SPI. > > > > It needs to be deterministrically by SPI, or you get no locality. > > Yes, SPI is an obvious choice. Theoretically there may be others > (e.g. use UDP encapsulation and send each ESP from a different port). Well, on the incomming side you can always distinguish the flows as long as the sending side used different SAs. So getting parallelism there is easy by using SPI, UDP encapsulation port, or whatever. > > > > With these kernel features in mind the following IPsec architecture > > > could be implied. The SPD is global for all CPUs, while SAD is split > > > into several copies, so that each CPU has its own SAD. We also need to > > > introduce a special entry in the SAD - "stub SA", that only > > constitutes > > > of a selector and has no associated SA. > > > > The read-only copy of the SPD can be replicated per-CPU, with the counters > > being updates by RCU. I don't understand your stub SA use. > > Because we need to indicate somewhere that SA with identical traffic selectors > exists for another CPU, but not for this one. This is dynamic information > and it cannot reside in SPD. We use the fallback SA as a 'stub one'. The difference is that we look it up in the global SAD and actually use it because it has key material negotiated. > > > This way the new SAs are created dynamically and treated equally - > > they > > > all live their own life - are re-keyed or even deleted if they are > > idle > > > for a long time. > > > > If there are SAs which are being used more than others, than there is > > something wrong. > > My point is that it doesn't matter how they are used - they > live their own life. Generally with a good enough randomizing > algorithm all of them should be used roughly equally. We don't require a fallback SA in the draft, we just recommend to have one. So in that sense, once created, all SAs live their own live. Steffen _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
