On Feb 21,  9:34am, jonathan@Pescadero.dsg.stanford.edu (Jonathan Stone) wrote:
-- Subject: Re: IPSEC in GENERIC

| I didn't keep careful records, I found the results too depressing.

I agree here.

| Someone with more time to spend on this might come up with enough
| datapoints to make an interesting paper, by tweaking various points in
| design space: disable the PCB cache for IPsec state, then measure
| oberhead (peak send rates, on a suitalbe machine/nic/switch combo),
| without IPsec, then with and without the PCB cache.
| 
| (TCP mandates one ACK every 2 data segments packets, and the PCB cache
| only helps for send processing, and only on connected TCP sockets, so
| receive processing will incur IPsec overhead (if Ipsec is enabled)
| whatever you do.)
| 
| Maybe I'll try to salvage a couple of P3 servers to run the tests:/.
| 
| 
| Christos... I'm also wondering about Thor's comment about packet
| fowarding.  I'm assuming Thor's comment is independent of any of my
| ad-hoc measurements.  My, er, nasty suspicious mind is wondering if
| Thor's results are from a low-end or embedded machine with a small
| I-cache (say, 16k or less).
| 
| If so, then just calling into the IPsec codepath (even if the IPsec
| code path checks for no active SADB/SDB entries where I recall it
| does), might trigger enough additional I-cache capacity misses to
| cause a noticeable penatly in peak packet-rate forwarding, for a
| CPU-limited (or I-cache-limited) packet forwarder.  OTOH, I'm doubtful
| about how many of us would acutally run GENERIC kernels on such a
| packet-forwarder.

With my changes (untested so far) you don't call into the ipsec
code unless there are SPD's active. So I think that you get the
benefit of not being penalized of having IPSEC compiled into the
kernel if you are not using it. I also think that FAST_IPSEC is a
lot faster than the regular IPSEC. I wish I had the time to run
some benchmarks on all of this...

christos