From owner-freebsd-current@FreeBSD.ORG Sat Aug 13 18:24:24 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 2566F16A41F; Sat, 13 Aug 2005 18:24:24 +0000 (GMT) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9148143D46; Sat, 13 Aug 2005 18:24:23 +0000 (GMT) (envelope-from mike@sentex.net) Received: from pumice3.sentex.ca (pumice3.sentex.ca [64.7.153.26]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j7DINLpn090845; Sat, 13 Aug 2005 14:23:21 -0400 (EDT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by pumice3.sentex.ca (8.13.3/8.13.3) with ESMTP id j7DIOMTq070075; Sat, 13 Aug 2005 14:24:22 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.3/8.13.3) with ESMTP id j7DIOLmm045712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Aug 2005 14:24:21 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.3.4.0.20050813102138.0644fe08@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sat, 13 Aug 2005 14:23:51 -0400 To: Pawel Jakub Dawidek From: Mike Tancsa In-Reply-To: <20050813074636.GH27996@garage.freebsd.pl> References: <20050812134511.GE25162@garage.freebsd.pl> <6.2.3.4.0.20050813012441.061d08b0@64.7.153.2> <20050813074636.GH27996@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 X-Scanned-By: MIMEDefang 2.51 on 64.7.153.26 Cc: FreeBSD-current Subject: Re: VIA/ACE PadLock integration with crypto(9). 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: Sat, 13 Aug 2005 18:24:24 -0000 At 03:46 AM 13/08/2005, Pawel Jakub Dawidek wrote: >On Sat, Aug 13, 2005 at 01:45:44AM -0400, Mike Tancsa wrote: >+> Is there something else that needs to be done to tell crypto(4) >or FAST_IPSEC to use the "hardware" in this case ? > >I'm not sure why you need to set net.inet.ipsec.crypto_support to 1 for >this. Shouldn't be needed. > >If you want to figure it out, you may place debug print into Will do. I will play with it over the weekend. Overnight I also let a copy of netperf run blasting various network tests across the IPSEC tunnel and all was as expected. I had to enable polling on the box as it was getting dangerously close to livelock with the high level of interrupts. At 1500 HZ its still quite fast, forwarding IPSEC traffic at 60Mb/s and the box is VERY responsive. Without the padlock.ko, it comes in just at 23Mb/s. +> Also, I came across a small ipsec bug while testing >+> >+> http://www.freebsd.org/cgi/query-pr.cgi?pr=84860 > >It could be RELENG_5 specific, as it uses rijndael implementation >which was removed after RELENG_5 (there is no sys/opencrypto/rijndael.c >anymore). Maybe rijndael version from sys/crypto/ handles it better? >This needs to be verified. Actually this happens in RELENG_6 as well. I have updated the PR with a crash dump and back trace. ---Mike