Date: Tue, 17 Aug 2010 12:47:05 -0700 From: Pyun YongHyeon <pyunyh@gmail.com> To: Jack Vogel <jfvogel@gmail.com> Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7 em problems (and RELENG_8) Message-ID: <20100817194705.GD6482@michelle.cdnetworks.com> In-Reply-To: <AANLkTi=UkuZ9wGTR2e=CBDmJMrbeGKiCP-U0bF8Vr2_3@mail.gmail.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> <AANLkTi=UkuZ9wGTR2e=CBDmJMrbeGKiCP-U0bF8Vr2_3@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <pyunyh@gmail.com> 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: <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<http://people.freebsd.org/%7Eyongari/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" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100817194705.GD6482>