Date: Wed, 1 Oct 2014 11:28:59 -0700 From: Nick Rogers <ncrogers@gmail.com> To: Nick Rogers <ncrogers@gmail.com> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, Adrian Chadd <adrian@freebsd.org> Subject: Re: ixgbe IXGBE_LEGACY_TX breaks build (patch/fix included) Message-ID: <CAKOb=YZBoj_T1NoknnNrqcZr_w5VpBJSxycZ_tngGEnv-P-auA@mail.gmail.com> In-Reply-To: <CAKOb=YaX0FPGwaw0cpHN3afHEXKYiQ=Dc8xQZGzbO8uX-uS=dA@mail.gmail.com> References: <CAKOb=YbkGYqHcnyc2qVR0o8DQAxpHFPqrzEt0C5mxvo7=rRNaA@mail.gmail.com> <CAJ-Vmom5Xsj1Pvcd_BVdohNwYYp8xO33%2BNiB5m8u6ZDBn3UcwA@mail.gmail.com> <CAKOb=Yaz9JmHNp==hGNRxT-2UD2wfJUB_5krmTgqUzxW4TdGBA@mail.gmail.com> <CAKOb=YaX0FPGwaw0cpHN3afHEXKYiQ=Dc8xQZGzbO8uX-uS=dA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Sep 17, 2014 at 8:17 AM, Nick Rogers <ncrogers@gmail.com> wrote: > > > On Tue, Aug 26, 2014 at 4:16 PM, Nick Rogers <ncrogers@gmail.com> wrote: > >> >> >> >> On Tue, Aug 26, 2014 at 3:36 PM, Adrian Chadd <adrian@freebsd.org> wrote: >> >>> Hi, >>> >>> I'm not surprised the legacy tx path has bitrotted there. >>> >>> Please file a bug with this - https://bugs.freebsd.org/submit/ - and >>> then just keep poking people until it's done. >>> >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193053 >> > > Poke. Looking for some triage? > Any chance we can get some kind of resolution on this before 10.1? It seems like simply upgrading the ixgbe driver with the latest from Intel fixes the problem. If that is not possible, the changes in the patch I posted are still working for me in production. > > >> >>> Thank! >>> >>> >>> -a >>> >>> >>> On 26 August 2014 13:42, Nick Rogers <ncrogers@gmail.com> wrote: >>> > Hello, >>> > >>> > I am trying to get the ixgbe driver + PF/ALTQ working under stable/9. >>> > Initially, loading a PF rulset with ALTQ enabled fails on an ix >>> interface, >>> > reporting "ix0: driver does not support altq". This is similar to the >>> > behavior over the last few years when dealing with the igb driver. >>> However, >>> > I have been using ALTQ + igb with great success by defining >>> IGB_LEGACY_TX >>> > in the e1000/igb driver code. I noticed that ixgbe has a similar define >>> > IXGBE_LEGACY_TX to enable the legacy, non-multiqueue transmit behavior, >>> > that also "enables" ALTQ support. >>> > >>> > After adding the IXGBE_LEGACY_TX define to ixgbe source, building the >>> > driver fails with the following compile errors: >>> > >>> > /usr/src/sys/dev/ixgbe/ixgbe.c: In function 'ixgbe_msix_que': >>> > /usr/src/sys/dev/ixgbe/ixgbe.c:1529: error: invalid type argument of >>> '->' >>> > (have 'struct ifaltq') >>> > /usr/src/sys/dev/ixgbe/ixgbe.c:1529: error: invalid type argument of >>> '->' >>> > (have 'struct ifaltq') >>> > /usr/src/sys/dev/ixgbe/ixgbe.c: In function 'ixgbe_local_timer': >>> > /usr/src/sys/dev/ixgbe/ixgbe.c:2077: error: 'struct tx_ring' has no >>> member >>> > named 'txq_task' >>> > /usr/src/sys/dev/ixgbe/ixgbe.c: In function >>> 'ixgbe_free_transmit_buffers': >>> > /usr/src/sys/dev/ixgbe/ixgbe.c:3255: error: 'struct tx_ring' has no >>> member >>> > named 'br' >>> > /usr/src/sys/dev/ixgbe/ixgbe.c:3256: error: 'struct tx_ring' has no >>> member >>> > named 'br' >>> > >>> > So it seems that the IXGBE_LEGACY_TX path no longer compiles >>> successfully, >>> > and perhaps never did? Using e1000 as a reference, fixing the pointer >>> > error, and looking at previous revisions of ixgbe.c, I was able to >>> come up >>> > with the following patch that got the driver to compile while having >>> > IXGBE_LEGACY_TX defined. Note that the following svn diff is against >>> HEAD, >>> > which as far as I can tell contains the same broken IXGBE_LEGACY_TX >>> path as >>> > stable/9 and stable/10. >>> > >>> > Index: ixgbe.c >>> > =================================================================== >>> > --- ixgbe.c (revision 270665) >>> > +++ ixgbe.c (working copy) >>> > @@ -1543,7 +1543,7 @@ >>> > IXGBE_TX_LOCK(txr); >>> > ixgbe_txeof(txr); >>> > #ifdef IXGBE_LEGACY_TX >>> > - if (!IFQ_DRV_IS_EMPTY(ifp->if_snd)) >>> > + if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) >>> > ixgbe_start_locked(txr, ifp); >>> > #else >>> > if (!drbr_empty(ifp, txr->br)) >>> > @@ -2091,7 +2091,11 @@ >>> > (paused == 0)) >>> > ++hung; >>> > else if (txr->queue_status == IXGBE_QUEUE_WORKING) >>> > +#ifndef IXGBE_LEGACY_TX >>> > taskqueue_enqueue(que->tq, &txr->txq_task); >>> > +#else >>> > + taskqueue_enqueue(que->tq, &que->que_task); >>> > +#endif >>> > } >>> > /* Only truely watchdog if all queues show hung */ >>> > if (hung == adapter->num_queues) >>> > @@ -3327,10 +3331,6 @@ >>> > tx_buffer->map = NULL; >>> > } >>> > } >>> > -#ifdef IXGBE_LEGACY_TX >>> > - if (txr->br != NULL) >>> > - buf_ring_free(txr->br, M_DEVBUF); >>> > -#endif >>> > if (txr->tx_buffers != NULL) { >>> > free(txr->tx_buffers, M_DEVBUF); >>> > txr->tx_buffers = NULL; >>> > =================================================================== >>> > >>> > Using a stable/9 kernel with the above patch allowed me to load my PF >>> > ruleset on a machine with an ixgbe interface and ALTQ enabled. i.e. I >>> no >>> > longer received the "driver does not support altq error". Queueing on >>> the >>> > ix interface now appears to work as it should. >>> > >>> > I am hoping someone can help verify my work and perhaps audit and >>> correct >>> > the IXGBE_LEGACY_TX path currently in the svn tree. >>> > >>> > Also, FWIW, here is relevant pciconf output for the ixbge card. >>> > >>> > ix0@pci0:1:0:0: class=0x020000 card=0x00038086 chip=0x10fb8086 >>> rev=0x01 >>> > hdr=0x00 >>> > vendor = 'Intel Corporation' >>> > device = '82599EB 10-Gigabit SFI/SFP+ Network Connection' >>> > class = network >>> > subclass = ethernet >>> > cap 01[40] = powerspec 3 supports D0 D3 current D0 >>> > cap 05[50] = MSI supports 1 message, 64 bit, vector masks >>> > cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled >>> > cap 10[a0] = PCI-Express 2 endpoint max data 128(512) link x8(x8) >>> > ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected >>> > ecap 0003[140] = Serial 1 0023faffff300715 >>> > ecap 000e[150] = unknown 1 >>> > ecap 0010[160] = unknown 1 >>> > ix1@pci0:1:0:1: class=0x020000 card=0x00038086 chip=0x10fb8086 >>> rev=0x01 >>> > hdr=0x00 >>> > vendor = 'Intel Corporation' >>> > device = '82599EB 10-Gigabit SFI/SFP+ Network Connection' >>> > class = network >>> > subclass = ethernet >>> > cap 01[40] = powerspec 3 supports D0 D3 current D0 >>> > cap 05[50] = MSI supports 1 message, 64 bit, vector masks >>> > cap 11[70] = MSI-X supports 64 messages in map 0x20 enabled >>> > cap 10[a0] = PCI-Express 2 endpoint max data 128(512) link x8(x8) >>> > ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected >>> > ecap 0003[140] = Serial 1 0023faffff300715 >>> > ecap 000e[150] = unknown 1 >>> > ecap 0010[160] = unknown 1 >>> > >>> > Thanks! >>> > >>> > -Nick >>> > _______________________________________________ >>> > freebsd-net@freebsd.org mailing list >>> > http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >> >> >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAKOb=YZBoj_T1NoknnNrqcZr_w5VpBJSxycZ_tngGEnv-P-auA>