From owner-freebsd-net@FreeBSD.ORG Sun Mar 8 20:00:14 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB78B106568E for ; Sun, 8 Mar 2009 20:00:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F1FB38FC14 for ; Sun, 8 Mar 2009 20:00:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n28K0Bns042749 for ; Sun, 8 Mar 2009 20:00:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n28K0B5B042748; Sun, 8 Mar 2009 20:00:11 GMT (envelope-from gnats) Date: Sun, 8 Mar 2009 20:00:11 GMT Message-Id: <200903082000.n28K0B5B042748@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Patrick =?ISO-8859-15?Q?Lamaizi=E8re?= Cc: Subject: Re: misc/132277: poor performance using criptodevice for IPSEC X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Patrick =?ISO-8859-15?Q?Lamaizi=E8re?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 20:00:17 -0000 The following reply was made to PR kern/132277; it has been noted by GNATS. From: Patrick =?ISO-8859-15?Q?Lamaizi=E8re?= To: bug-followup@FreeBSD.org Cc: Vasile Marii Subject: Re: misc/132277: poor performance using criptodevice for IPSEC Date: Sun, 8 Mar 2009 20:56:01 +0100 Le Tue, 3 Mar 2009 07:42:44 GMT, Vasile Marii : Hi, > Does anybody have any better results on glxsb or via?(i mean a netperf > test between two machines) or there is a hack or a setting in the > kernel or somewhere else? I've made some tests on IPsec with glxsb and the performances are very bad (around 14 Mbits). I think the problem is that glxsb handles only one request at a time. When it is busy, it blocks the Open Crypto Framework with ERESTART and it unblocks the OCF when the previous request is completed. Then the OCF has to wake up and to resubmit the request. It looks like this performs very badly when using it with IPsec. If glxsb processes the requests synchronously it performs quite better, around 50 Mbits. I will look for glxsb.