From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 18:28:08 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9176816A418 for ; Fri, 17 Aug 2007 18:28:08 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 079C613C48D for ; Fri, 17 Aug 2007 18:28:07 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 75133 invoked from network); 17 Aug 2007 18:19:10 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 17 Aug 2007 18:19:10 -0000 Message-ID: <46C5E8B6.7070807@freebsd.org> Date: Fri, 17 Aug 2007 20:28:06 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Andrew Gallatin References: <18116.43755.107638.103132@grasshopper.cs.duke.edu> In-Reply-To: <18116.43755.107638.103132@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: IPSEC disables TSO 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: Fri, 17 Aug 2007 18:28:08 -0000 Andrew Gallatin wrote: > When tracking down an mxge 10GbE performance issue, I noticed that > simply compiling IPSEC into the kernel totally destroys 10GbE transmit > performance because it will silently disable TSO. > > The problem seems to be at least that the test on line 463 of > tcp_output.c (tp->t_inpcb->inp_sp == NULL) will always be > false. If I comment that line out, TSO works as normal > (though I have no idea what would happen on an IPSEC connection). > > Is there some way to make this not happen? I believe that the mxge > user simply wanted to run some handful of applications through ipsec > tunnels (perhaps even on a different NIC entirely). The idea was that ip->t_inpcb->inp_sp is NULL when no SP is active. This may no longer be the case after the FAST_IPSEC -> IPSEC switch and this test may have to be reevaluated. -- Andre