From owner-svn-src-head@FreeBSD.ORG Mon Mar 31 04:36:20 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0AE573BE; Mon, 31 Mar 2014 04:36:20 +0000 (UTC) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BEDB861B; Mon, 31 Mar 2014 04:36:19 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id fp1so7482777pdb.28 for ; Sun, 30 Mar 2014 21:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=KB6o/G/orI7pgPH+03ox0PoiEdn2eYwVlkToxe+Q8So=; b=pjzQXmy3Fjxwxg5mpGe7ErO1V6aPKZObJmtv/Hi+QNDj6Kvt79kcYq4yWM3mqhHz/R EYdLk6Q4P7FHirovWXXhhug3yKdW7jrMJ8l6/54FwfiO0jO/vlIKll1Q3HWSb7GGIRmk 0d1EZD+TJEyWKhf9zTMJKKBDqzxHuVir6HJsWbjL0wPnt56I1DLqpDsGflXNRl116L2M Z3EpsUq4IH83/eEJR0rppAfREYolzXJiUAnv0Ndchdo2k6nFn+UF3zsI59aLrIU6FjDc FSJg+07msvOke1VXDHifsSgjUg2C8KqIN7SxAAfU5wlrI2aZbzyyWIVBNIC3uylhDFgc Mtzw== X-Received: by 10.66.240.130 with SMTP id wa2mr23001332pac.73.1396240579018; Sun, 30 Mar 2014 21:36:19 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id nc1sm40465086pbc.32.2014.03.30.21.36.16 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 30 Mar 2014 21:36:18 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 31 Mar 2014 13:36:12 +0900 From: Yonghyeon PYUN Date: Mon, 31 Mar 2014 13:36:12 +0900 To: John-Mark Gurney Subject: Re: svn commit: r263957 - in head/sys: dev/age dev/alc dev/ale dev/bce dev/bge dev/fxp dev/jme dev/msk dev/nfe dev/sge pci Message-ID: <20140331043612.GB1359@michelle.cdnetworks.com> References: <201403310154.s2V1sxXY010836@svn.freebsd.org> <20140331040058.GV60889@funkthat.com> <20140331042535.GA1359@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140331042535.GA1359@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Pyun YongHyeon X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: pyunyh@gmail.com List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 04:36:20 -0000 On Mon, Mar 31, 2014 at 01:25:35PM +0900, Yonghyeon PYUN wrote: > On Sun, Mar 30, 2014 at 09:00:59PM -0700, John-Mark Gurney wrote: > > Pyun YongHyeon wrote this message on Mon, Mar 31, 2014 at 01:54 +0000: > > > Author: yongari > > > Date: Mon Mar 31 01:54:59 2014 > > > New Revision: 263957 > > > URL: http://svnweb.freebsd.org/changeset/base/263957 > > > > > > Log: > > > Increase the number of TX DMA segments from 32 to 35. It turned > > > out 32 is not enough to support a full sized TSO packet. > > > While I'm here fix a long standing bug introduced in r169632 in > > > bce(4) where it didn't include L2 header length of TSO packet in > > > the maximum DMA segment size calculation. > > > > I assume all of the hardware supports this increase? > > > > Yes. Data sheet does not mention about such limitation. txp(4) > has a limitation on the number of TX segments but I didn't > implement TSO in txp(4). > > > Also, is there a reason to only increase up to 35 and not something > > larger, like 64? Is there a memory or performance penalty? > > > > If 64 does not overflow kernel stack we can also bump the number to > 64. Hmm, I think I didn't answer on performance penalty. If hardware allows only a single outstanding DMA read operation, having multiple TX buffers would result in lower performance. However it's common to have multiple TX buffers in TSO so I don't think it could change performance number in TSO path. And I think most high end server NICs support multiple outstanding DMA read operation.