From owner-freebsd-stable@freebsd.org Fri Aug 21 21:46:16 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66E5A9C0558; Fri, 21 Aug 2015 21:46:16 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id EA31B1F43; Fri, 21 Aug 2015 21:46:15 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:19NhgxYJD9UAAixx11n0lZD/LSx+4OfEezUN459isYplN5qZpcW/bnLW6fgltlLVR4KTs6sC0LqN9f25EjRZqb+681k8M7V0HycfjssXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aJBzzOEJPK/jvHcaK1oLsh7v0psSYO1wArQH+SI0xBS3+lR/WuMgSjNkqAYcK4TyNnEF1ff9Lz3hjP1OZkkW0zM6x+Jl+73YY4Kp5pIZoGJ/3dKUgTLFeEC9ucyVsvJWq5lH/Sl6X92YaQ2U+nR9BAgyD5xb/Gt/duy37u+418jOTO8ztVvhgVT2k6bZDQwSuiDoFNngw+yfWjpojorhcpUebphd8i6vda4KROf82KrnYdNgZQWdEdttWWDFMBpu8KYAGWblSdd1EppXw8gNd5SC1AhOhUaa2kmdF X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BEAgBFm9dV/61jaINdDoNhaQaDH7pEAQmBbQqFMUoCgW0UAQEBAQEBAQGBCYIdggcBAQQBAQEgBCcgCwULAgEIGAICDRkCAicBCSYCBAEHBwQBGgIEiA0NuHWVfwEBAQEBAQEBAQEBAQEBAQEBARYEgSKKMoQyBgEBHDQHgmmBQwWVLYUFhQiELIdKiH6ESYNoAiaCDhyBFVoiMwd/CBcjgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,723,1432612800"; d="scan'208";a="232337900" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 21 Aug 2015 17:46:08 -0400 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id E45C915F55D; Fri, 21 Aug 2015 17:46:08 -0400 (EDT) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id l7J6bMg-1Frh; Fri, 21 Aug 2015 17:46:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 25FC715F563; Fri, 21 Aug 2015 17:46:08 -0400 (EDT) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9cPtlj9JK9l1; Fri, 21 Aug 2015 17:46:08 -0400 (EDT) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 0244415F55D; Fri, 21 Aug 2015 17:46:08 -0400 (EDT) Date: Fri, 21 Aug 2015 17:46:07 -0400 (EDT) From: Rick Macklem To: pyunyh@gmail.com, Daniel Braniss Cc: Hans Petter Selasky , FreeBSD stable , FreeBSD Net , Slawa Olhovchenkov , Gleb Smirnoff , Christopher Forgeron Message-ID: <1153838447.28656490.1440193567940.JavaMail.zimbra@uoguelph.ca> In-Reply-To: <20150820023024.GB996@michelle.fasterthan.com> References: <1D52028A-B39F-4F9B-BD38-CB1D73BF5D56@cs.huji.ac.il> <55D333D6.5040102@selasky.org> <1325951625.25292515.1439934848268.JavaMail.zimbra@uoguelph.ca> <55D429A4.3010407@selasky.org> <20150819074212.GB964@michelle.fasterthan.com> <55D43615.1030401@selasky.org> <2013503980.25726607.1439989235806.JavaMail.zimbra@uoguelph.ca> <20150820023024.GB996@michelle.fasterthan.com> Subject: Re: ix(intel) vs mlxen(mellanox) 10Gb performance MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.12] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF34 (Win)/8.0.9_GA_6191) Thread-Topic: ix(intel) vs mlxen(mellanox) 10Gb performance Thread-Index: Zq6MViNwCd2Hhr1mTS/9wAk6UKubQA== X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2015 21:46:16 -0000 Yonghyeon PYUN wrote: > On Wed, Aug 19, 2015 at 09:00:35AM -0400, Rick Macklem wrote: > > Hans Petter Selasky wrote: > > > On 08/19/15 09:42, Yonghyeon PYUN wrote: > > > > On Wed, Aug 19, 2015 at 09:00:52AM +0200, Hans Petter Selasky wrote: > > > >> On 08/18/15 23:54, Rick Macklem wrote: > > > >>> Ouch! Yes, I now see that the code that counts the # of mbufs is > > > >>> before > > > >>> the > > > >>> code that adds the tcp/ip header mbuf. > > > >>> > > > >>> In my opinion, this should be fixed by setting if_hw_tsomaxsegcount > > > >>> to > > > >>> whatever > > > >>> the driver provides - 1. It is not the driver's responsibility to > > > >>> know if > > > >>> a tcp/ip > > > >>> header mbuf will be added and is a lot less confusing that expecting > > > >>> the > > > >>> driver > > > >>> author to know to subtract one. (I had mistakenly thought that > > > >>> tcp_output() had > > > >>> added the tc/ip header mbuf before the loop that counts mbufs in the > > > >>> list. > > > >>> Btw, > > > >>> this tcp/ip header mbuf also has leading space for the MAC layer > > > >>> header.) > > > >>> > > > >> > > > >> Hi Rick, > > > >> > > > >> Your question is good. With the Mellanox hardware we have separate > > > >> so-called inline data space for the TCP/IP headers, so if the TCP > > > >> stack > > > >> subtracts something, then we would need to add something to the limit, > > > >> because then the scatter gather list is only used for the data part. > > > >> > > > > > > > > I think all drivers in tree don't subtract 1 for > > > > if_hw_tsomaxsegcount. Probably touching Mellanox driver would be > > > > simpler than fixing all other drivers in tree. > > > > > > > >> Maybe it can be controlled by some kind of flag, if all the three TSO > > > >> limits should include the TCP/IP/ethernet headers too. I'm pretty sure > > > >> we want both versions. > > > >> > > > > > > > > Hmm, I'm afraid it's already complex. Drivers have to tell almost > > > > the same information to both bus_dma(9) and network stack. > > > > > > Don't forget that not all drivers in the tree set the TSO limits before > > > if_attach(), so possibly the subtraction of one TSO fragment needs to go > > > into ip_output() .... > > > > > Ok, I realized that some drivers may not know the answers before > > ether_ifattach(), > > due to the way they are configured/written (I saw the use of > > if_hw_tsomax_update() > > in the patch). > > I was not able to find an interface that configures TSO parameters > after if_t conversion. I'm under the impression > if_hw_tsomax_update() is not designed to use this way. Probably we > need a better one?(CCed to Gleb). > > > > > If it is subtracted as a part of the assignment to if_hw_tsomaxsegcount in > > tcp_output() > > at line#791 in tcp_output() like the following, I don't think it should > > matter if the > > values are set before ether_ifattach()? > > /* > > * Subtract 1 for the tcp/ip header mbuf that > > * will be prepended to the mbuf chain in this > > * function in the code below this block. > > */ > > if_hw_tsomaxsegcount = tp->t_tsomaxsegcount - 1; > > > > I don't have a good solution for the case where a driver doesn't plan on > > using the > > tcp/ip header provided by tcp_output() except to say the driver can add one > > to the > > setting to compensate for that (and if they fail to do so, it still works, > > although > > somewhat suboptimally). When I now read the comment in sys/net/if_var.h it > > is clear > > what it means, but for some reason I didn't read it that way before? (I > > think it was > > the part that said the driver didn't have to subtract for the headers that > > confused me?) > > In any case, we need to try and come up with a clear definition of what > > they need to > > be set to. > > > > I can now think of two ways to deal with this: > > 1 - Leave tcp_output() as is, but provide a macro for the device driver > > authors to use > > that sets if_hw_tsomaxsegcount with a flag for "driver uses tcp/ip > > header mbuf", > > documenting that this flag should normally be true. > > OR > > 2 - Change tcp_output() as above, noting that this is a workaround for > > confusion w.r.t. > > whether or not if_hw_tsomaxsegcount should include the tcp/ip header > > mbuf and > > update the comment in if_var.h to reflect this. Then drivers that don't > > use the > > tcp/ip header mbuf can increase their value for if_hw_tsomaxsegcount by > > 1. > > (The comment should also mention that a value of 35 or greater is much > > preferred to > > 32 if the hardware will support that.) > > > > Both works for me. My preference is 2 just because it's very > common for most drivers that use tcp/ip header mbuf. Thanks for this comment. I tend to agree, both for the reason you state and also because the patch is simple enough that it might qualify as an errata for 10.2. I am hoping Daniel Braniss will be able to test the patch and let us know if it improves performance with TSO enabled? rick > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >