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.
I could guess that the fallback SA *does* require locks.
> 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.
> 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.
> 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.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
