William Allen Simpson <william.allen.simp...@gmail.com> wrote:
> In modern CPUs, there's always an issue with cache lines. But for a
> parallel implementation, it really isn't going to matter. The CPU
> that finishes last and needs to check the ICV isn't particularly
> likely to be the CPU that processed the initial header anyway.
SGI did some extensive analysis on their multiprocessors around 1995.
I have the references somewhere if you want them.
I did a lot of analysis and reading (on paper, in the library...) at the time
about architectures for parallel firewalls.
SGI's conclusion (born out by architectures today) was that layer-by-layer
parallelism (i.e. Solaris STREAMS) was a total fail. You have to keep the
packet with the same CPU all way up.
The Linux kernel has always tried to do this, and most of the focus in
hardware systems is to do the inverse-demux as early as physically possible,
and then stick with it.
SGI also concluded, at the time of 100Mhz CPUs and no hardware assist, that
the cost of doing IPsec (or SSL at the time), made the difference between
these vertical and horizontal parallelism architectures unmeasureable. So
might as well go with the one that works best for non-encrypted traffic, and
is easier to code/debug.
> As a matter of historical record, this was also a long debate for TCP.
> The default is leading, and there is a TCP option for trailing checksum.
> Might it be a non-default option negotiated per SPI?
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
