--DocE+STaALJfprDB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Sun, Jun 12, 2005 at 06:01:50PM -0400, Thor Lancelot Simon wrote:
> On Sun, Jun 12, 2005 at 02:38:58PM -0700, Jonathan Stone wrote:
>
> > IIRC, Sam Leffler added support for the newer hifn chips to the
> > FreeBSD-4 driver and confirmed that they worked; if so, that's one
> > "known good" data-point to work from.
> >
> > (Hmm, its not as simple as running out of hardware contexts, is it?)
>
> I don't think it is -- unfortunately I can't tear my router apart right
> now to put the 1401 back into it to test, but I believe I reproduced
> the problem quickly after a boot; the details should be in the mail I
> sent you about it a couple of months ago, I think (I hope?).
>
> A user on one of the mailing lists also mentioned that he can't seem to
> get any hash operations to work right with the hifn driver. I didn't
> try to reproduce that, but it's an interesting line of attack: both
> IPsec and SSH are indeed going to use keyed hashes while, for example,
> "openssl speed des" or "openssl speed aes", just as obvious tests one
> could run, won't -- maybe the problem is _only_ with the hash functions?
I'm the user who reported the problems with the hash operations. I've
attached a patch which fixes the problem. With the patch, the VPN1401
(hifn 7955) driver works fine for me, but I'm using it on QNX (haven't
tested on NetBSD).
The result of the hash is stored 12 bytes from the beginning of the
results buffer. hifn_callback() adds 12 bytes already, and the current
driver also adds increments the macbuf pointer by 12 before calling the
hifn_callback. The attached patch basically just removes the macbbuf +=
12; lines.
I only ever had problems with the hash functions, but I've also applied
the patch that was sent out last week which fixes PR 30487.
>
> I believe I noted in my earlier mail that there was almost no difference
> in speed when doing "openssl speed aes" using the /dev/crypto engine or
> even if I removed /dev/crypto entirely to force use of the software
> engine. That doesn't seem right, either, but I did confirm at the time
> that requests seemed to be in fact being made on the crypto device, so
> again I'm... not sure what to think.
>
> Thor
I see a noticeable performance increase when using FAST_IPSEC, but I
haven't tested it yet with OpenSSL. I've also noticed that the current
OpenSSL sources don't use /dev/crypto for hashing, only for encryption.
Regards,
Gilles Roy
--DocE+STaALJfprDB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=hifnpatch
*** hifn7751.c 2005-06-14 09:09:20.000000000 -0400
--- hifn7751.c 2005-06-14 09:15:10.000000000 -0400
***************
*** 1907,1913 ****
if (i != HIFN_D_RES_RSIZE) {
struct hifn_command *cmd;
- u_int8_t *macbuf = NULL;
HIFN_RES_SYNC(sc, i, BUS_DMASYNC_POSTREAD);
cmd = dma->hifn_commands[i];
--- 1927,1932 ----
***************
*** 1915,1926 ****
/*("hifn_intr: null command slot %u", i)*/);
dma->hifn_commands[i] = NULL;
! if (cmd->base_masks & HIFN_BASE_CMD_MAC) {
! macbuf = dma->result_bufs[i];
! macbuf += 12;
! }
!
! hifn_callback(sc, cmd, macbuf);
hifnstats.hst_opackets++;
}
--- 1934,1940 ----
/*("hifn_intr: null command slot %u", i)*/);
dma->hifn_commands[i] = NULL;
! hifn_callback(sc, cmd, dma->result_bufs[i]);
hifnstats.hst_opackets++;
}
***************
*** 2356,2370 ****
if ((dma->resr[i].l & htole32(HIFN_D_VALID)) == 0) {
/* Salvage what we can. */
- u_int8_t *macbuf;
-
- if (cmd->base_masks & HIFN_BASE_CMD_MAC) {
- macbuf = dma->result_bufs[i];
- macbuf += 12;
- } else
- macbuf = NULL;
hifnstats.hst_opackets++;
! hifn_callback(sc, cmd, macbuf);
} else {
if (cmd->src_map == cmd->dst_map) {
bus_dmamap_sync(sc->sc_dmat, cmd->src_map,
--- 2370,2377 ----
if ((dma->resr[i].l & htole32(HIFN_D_VALID)) == 0) {
/* Salvage what we can. */
hifnstats.hst_opackets++;
! hifn_callback(sc, cmd, dma->result_bufs[i]);
} else {
if (cmd->src_map == cmd->dst_map) {
bus_dmamap_sync(sc->sc_dmat, cmd->src_map,
--DocE+STaALJfprDB--