Hi Steffen, > > > 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.
Then my next question is - how the sending side decides whether to one of use per-CPU SAs or the fallback SA? My guess that the packet is handled by some kernel thread (i.e. by some CPU), so once this CPU figures out that it doesn't have an SA - I assume it uses the fallback SA then. Is it right? If so, then why it cannot hand over the packet to the CPU that for sure has the needed SA (this CPU can be indicated in the stub SA entry)? In both cases some locking is required - does the latter case require much more 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. I presume the packet is handed over to a particular CPU that does have the SA, so only one per-CPU database is looked ip. [snipped] > > > 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. Another issue that is not clear from the draft - how per-CPU SAs are created. Consider the situation when an outgoing packet is handled by a CPU and there is no per-CPU Sa to handle it. Then, I assume, the fallback SA is used. My question - in this case does this CPU additionally requests IKE to create a per-CPU SA for it? If so, then what happens if the other side has indicated that no more per-CPU SAs is allowed - is it saved somewhere, so that future outgoing packets handled by CPUs with no per-CPU SA, don't trigger requests to create it anymore? > > > > 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. Hmm, my impression from reading the draft is that it is not so: Section 3: When negotiating CPU specific Child SAs, the first SA negotiated either in an IKE_AUTH exchange or CREATE_CHILD_SA is called Fallback SA. This Fallback Child SA (or its rekeyed successors) MUST remain active for the lifetime of the IPsec session to ensure that there is always a Child SA that can be selected to send traffic over, in case a per-resource Child SA is not available. The Fallback SA MUST NOT be deleted while any per-resource Child SAs are still present. Section 4: The Fallback Child SA MUST NOT be deleted when idle, as it is likely to be idle if enough per-CPU Child SAs are installed. I think that these BCP14 requirements make the fallback SA very special. Regards, Valery. > Steffen _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
