From owner-freebsd-current@FreeBSD.ORG Tue Aug 9 22:22:18 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 CFE8816A41F; Tue, 9 Aug 2005 22:22:18 +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 588EC43D5E; Tue, 9 Aug 2005 22:22:18 +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 j79MMDms055935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Aug 2005 15:22:14 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42F92CC3.7060609@errno.com> Date: Tue, 09 Aug 2005 15:22:59 -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> <42F82E23.9010307@errno.com> <42F884C3.20505@freebsd.org> In-Reply-To: <42F884C3.20505@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 22:22:19 -0000 Andre Oppermann wrote: > Sam Leffler wrote: > >> 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. > > > I don't know the crypto(9) API very well but from reading the man page > and the Cavium crypto processor documentation there seems to be a rather > nice fit. What Cavium gets right is their kick-ass DMA engine on the > processors. Very good to write drivers for and very efficient and > performant on the PCI bus. There is microcode to be loaded onto the > cards but it is a rather small code segment and all the critical functions > are built in hardware (from the docs). I agree that the FreeBSD driver > wasn't written by someone with great BSD driver experience. On the other > hand they managed to put all the kernel level driver stuff under the BSD > license. For some reason the crypto operation setup code in the OpenSSL > patch is proprietary code. OTOH pretty much the same code functionality > in the Linux FreeSWAN HW accel patch is under a BSD license. From that > point on there is very little preventing a new, properly written FreeBSD > driver from happening. I can send you all code parts under permissible > licenses for a sneek peek. If there is genuine interest in writing such a > driver I can try to get you the programmer docs with an NDA permitting a > new > BSD driver. My account manager is pretty high up in the food chain there. > He's certainly the right guy to talk to and take the decision. > I can only guess you have been looking at Cavium's low-end parts if the dma engine is what impresses you. There are plenty of crypto parts that can use a full 64/133 PCI bus (and more); in fact many companies assign the dma engine work to summer interns 'cuz it's so drop-dead easy (mind you I've also seen plenty of dma engines the _looked_ like they were designed by summer interns :)). Cavium's high-end parts that promise very high throughput will perform suboptimally if hooked up to crypto(9) because you simply cannot keep the crypto engine(s) busy. You must use the higher-level directives that do things like processs complete ipsec frames. I have more that passing experience with Cavium. You might want to try actually working with them and not just reading docs. Sam