Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 17 Aug 2010 12:14:20 -0700
From:      Pyun YongHyeon <pyunyh@gmail.com>
To:        Mike Tancsa <mike@sentex.net>
Cc:        freebsd-stable@freebsd.org, jfvogel@gmail.com
Subject:   Re: RELENG_7 em problems (and RELENG_8)
Message-ID:  <20100817191420.GB6482@michelle.cdnetworks.com>
In-Reply-To: <20100817185208.GA6482@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>

next in thread | previous in thread | raw e-mail | index | archive | help
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: <ACPI PCI bus> on pcib3
> > em4: <Intel(R) PRO/1000 Network Connection 7.0.5> 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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100817191420.GB6482>