From owner-freebsd-stable@FreeBSD.ORG Tue Aug 17 19:47:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3A6D1065672 for ; Tue, 17 Aug 2010 19:47:08 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id BE1EA8FC20 for ; Tue, 17 Aug 2010 19:47:08 +0000 (UTC) Received: by pxi17 with SMTP id 17so3086431pxi.13 for ; Tue, 17 Aug 2010 12:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=cKj1v7SfYJA0syLOfC0UEwdha5SiYrFggZN6zNFbiOQ=; b=GueN+npk2VzWNsQaqpkJ4PHHmY53LhURDYACdAHRZjNaOI8nJM7u9IYxmYD6Fp1Gf/ aQCvJ60mBcJbFZM/t6lqUAYqiyZOmx2uLKlCWIrfROKV7QyT/XhRnH457acb4Wb1UHHR JwApFAPnkGoSwVJMIC8m22jNxN7YHwG1lb53w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=TjVps/TdmVjRQByn4WiVWDLHFCZ7zplzaTF2BQJV5vDLO2tGjoWUWjIgQUXpTCNyMx PD71WBukPo2GnH/vb8iIImDGdSfteZlvqwntwiJbQnBKxDo01eJeUxoa3F2/63KG2Vgp 5W1yVXNyHPWFfhwL1f4r3pnG4DJRXTRP3Gov4= Received: by 10.142.253.12 with SMTP id a12mr6166628wfi.251.1282074428294; Tue, 17 Aug 2010 12:47:08 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id v38sm10106822wfh.12.2010.08.17.12.47.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 17 Aug 2010 12:47:06 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 17 Aug 2010 12:47:05 -0700 From: Pyun YongHyeon Date: Tue, 17 Aug 2010 12:47:05 -0700 To: Jack Vogel Message-ID: <20100817194705.GD6482@michelle.cdnetworks.com> References: <201006102031.o5AKVCH2016467@lava.sentex.ca> <201007021739.o62HdMOU092319@lava.sentex.ca> <20100702193654.GD10862@michelle.cdnetworks.com> <201008162107.o7GL76pA080191@lava.sentex.ca> <20100817185208.GA6482@michelle.cdnetworks.com> <20100817191420.GB6482@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7 em problems (and RELENG_8) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 19:47:09 -0000 On Tue, Aug 17, 2010 at 12:34:31PM -0700, Jack Vogel wrote: > I believe the requirement of a context descriptor for most frames in the igb > driver > is just the way the hardware works, I've looked over the Linux driver again > and it > looks like they require the same. I don't believe its a big deal, just the > added > descriptor for the frame. > Setting up context does not cost much. The real cost comes from stopping requesting DMA for next packet whenever a new context is written. AFAIK Linux always added a new checksum context. I don't know whether Linux cares about the cost of refilling pipeline or measured the performance differences. FreeBSD noticed the difference on em(4) controllers and took appropriate action to take full advantage of the hardware feature, I think. I have to experiment how igb(4) works when it is told to reuse configured context(both checksum and TSO context). > Jack > > > On Tue, Aug 17, 2010 at 12:14 PM, Pyun YongHyeon wrote: > > > On Tue, Aug 17, 2010 at 11:52:08AM -0700, Pyun YongHyeon wrote: > > > On Mon, Aug 16, 2010 at 05:07:11PM -0400, Mike Tancsa wrote: > > > > Hi Jack, > > > > FYI, I am still seeing this same problem on RELENG_8 (code > > > > as of today). Unfortunately I cant try Pyun's patch since the > > > > underlying code has changed since then. > > > > > > > > em4@pci0:3:0:0: class=0x020000 card=0x34ec8086 chip=0x10d38086 > > > > rev=0x00 hdr=0x00 > > > > vendor = 'Intel Corporation' > > > > device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' > > > > class = network > > > > subclass = ethernet > > > > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > > > > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > > > > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > > > > cap 11[a0] = MSI-X supports 5 messages in map 0x1c > > > > > > > > pci3: on pcib3 > > > > em4: port 0x1000-0x101f > > > > mem 0xb1900000-0xb191ffff,0xb1920000-0xb1923fff irq 16 at device 0.0 on > > pci3 > > > > em4: Using MSI interrupt > > > > em4: [FILTER] > > > > em4: Ethernet address: 00:15:17:ed:3e:c4 > > > > > > > > > > Here is updated patch for HEAD and stable/8. > > > http://people.freebsd.org/~yongari/em.csum_tso.20100817.patch > > > > > > It seems to work as expected under my limited environments. If > > > you're using multiple Tx queues with em(4) it would be better to > > > disable Tx checksum offloading as driver always have to create a > > > new checksum context for each frame. This will effectively disable > > > pipelined Tx data DMA which in turn greatly slows down Tx > > > performance for small sized frames. The reason driver have to > > > create a new checksum context when it uses multiple Tx queues comes > > > from hardware limitation. The controller tracks only for the last > > > context descriptor that was written such that driver does not know > > > the state of checksum context configured in other Tx queue. > > > Hope this helps. > > > > > > > For igb(4) controllers, it seems we also need a way to avoid > > creating a new checksum context for every Tx frame as we did in > > em(4). Unlike em(4) controllers, igb(4) seems to maintain context > > per queue such that we can safely reuse previously configured > > context for a queue. > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > >