ixgbe IXGBE_LEGACY_TX breaks build (patch/fix included)

[Adrian Chadd]

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.

Thank!


-a


On 26 August 2014 13:42, Nick Rogers <ncrogers at 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 at 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 at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"