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. > > 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). > > 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. > > 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. Regards, Valery. > -- > Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
