Subject: Re: Hifn crypto driver: does it work for anyone?
To: None <email@example.com>
From: Jonathan Stone <jonathan@Pescadero.dsg.stanford.edu>
Date: 10/17/2005 14:11:45
In message <E1ERaHu-0002NHfirstname.lastname@example.org>Jonathan Stone writes
>In message <20051016193507.GA2806@panix.com>, Thor Lancelot Simon writes:
>>I've been working on the Hifn crypto driver recently and have noticed
>>something startling: in a kernel with pseudo-device crypto and options
>>FAST_IPSEC, after the system has been running for a short while, all
>>crypto requests fail.
>How many device contexts are you allocating? If (dim) memory serves,
>the driver knows only about the lowest-common-denominator. I beleive
>the Soekris cards have external SRAM which could, in principle, be
>used for additional contexts; but the driver doesn't support that.
specifically, that'd be the "return (ENOMEM);" in hifn_newsession(),
around line 1991 in netbsd-3 source. Can you instrument that if()
branch (with printf()s or whatever) and let me know what you see?
If it's not obvious, each IPsec SA will consume a context, in addition
to each contexts allocated via userspace ioctl()s to /dev/crypto.
... did I ever commit that draft mannage I had kicking around for review?
>I know that at one point I exhausted the hardware-supported contexts,
>when talking to hundedrs of IPsec peers. That was using my own private
>mutant kernel (before I committed my port of Fast-IPSec), so I guess
>it's possilbe that fallback to software crypto never worked, or
>(less likely) got broken when other people reworked the OCF APIs.
>>This causes ssh to not work (since openssl uses /dev/crypto if present)
>>and it causes IPsec to not work, since encryption of every packet fails.
>>So, it seems like the RNG now works, but nothing else does. Has anyone
>>else had better luck with this driver? I'm using two different 7955