From owner-freebsd-current@FreeBSD.ORG Tue Aug 9 04:15:52 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 97B6E16A41F; Tue, 9 Aug 2005 04:15:52 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 446CD43D48; Tue, 9 Aug 2005 04:15:52 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.93] ([66.127.85.93]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j794Foms051228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Aug 2005 21:15:51 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42F82E23.9010307@errno.com> Date: Mon, 08 Aug 2005 21:16:35 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre Oppermann References: <42475.1123513974@phk.freebsd.dk> <42F786FC.1090805@freebsd.org> In-Reply-To: <42F786FC.1090805@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Poul-Henning Kamp , Michael Reifenberger , freebsd-current@freebsd.org, Pawel Jakub Dawidek , Mike Tancsa Subject: Re: Hifn driver in SMP (was Re: GELI - disk encryption GEOM class committed.) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2005 04:15:52 -0000 Andre Oppermann wrote: > Poul-Henning Kamp wrote: > >> I belive there is a bug in the HiFn chips that makes them do a soft reset >> under some set of circumstances which we have never been able to nail >> down. >> >> I have contacted HiFn about this and asked for a workaround, but >> they seem somewhat less than eager to work the case. >> >> I belive the message before last was that they hard reproduced it. >> >> The last message was from somebody going through the piles on a >> former employees table. > > > What's the deal with HiFn? IMHO Cavium are way better and much more > performant. > Not sure how you come to this conclusion about Cavium. Last time I looked at their h/w it was heavily firmware-based and the whole environment was problematic to integrate with crypto(9). OTOH it wasn't clear that integrating their stuff through the crypto subsystem would most effectively use their h/w; much better to integrate directly to ipsec and/or ssl using higher-level commands--just like hifn, broadcom, safenet, and everybody else. I also have my opinions about the quality of their code but that's another matter. Sam