Date: Thu, 16 Aug 2007 12:56:22 -0700 From: "Kip Macy" <kip.macy@gmail.com> To: "Andrew Gallatin" <gallatin@cs.duke.edu> Cc: freebsd-current@freebsd.org Subject: Re: IPSEC disables TSO Message-ID: <b1fa29170708161256v281889bcka9325164c1242d9d@mail.gmail.com> In-Reply-To: <b1fa29170708161253q6c96f8b7k6fd807b93460fd02@mail.gmail.com> References: <18116.43755.107638.103132@grasshopper.cs.duke.edu> <b1fa29170708161253q6c96f8b7k6fd807b93460fd02@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8/16/07, Kip Macy <kip.macy@gmail.com> wrote: > On 8/16/07, Andrew Gallatin <gallatin@cs.duke.edu> 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). > > IPSEC encrypts the TCP header - how is the card going to do TSO? I thought about this after sending and realized that the appropriate response is that IPSEC needs to be careful to disable TSO when its in use for a connection. What you're seeing was most likely done as an expedient. -Kip
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b1fa29170708161256v281889bcka9325164c1242d9d>