Date: Wed, 17 Sep 2014 08:17:28 -0700 From: Nick Rogers <ncrogers@gmail.com> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: ixgbe IXGBE_LEGACY_TX breaks build (patch/fix included) Message-ID: <CAKOb=YaX0FPGwaw0cpHN3afHEXKYiQ=Dc8xQZGzbO8uX-uS=dA@mail.gmail.com> In-Reply-To: <CAKOb=Yaz9JmHNp==hGNRxT-2UD2wfJUB_5krmTgqUzxW4TdGBA@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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? > >> 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=YaX0FPGwaw0cpHN3afHEXKYiQ=Dc8xQZGzbO8uX-uS=dA>