From owner-freebsd-net@FreeBSD.ORG Wed Oct 1 18:29:02 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4335B6C8; Wed, 1 Oct 2014 18:29:02 +0000 (UTC) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 75F6C1B0; Wed, 1 Oct 2014 18:29:01 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id hz20so942993lab.11 for ; Wed, 01 Oct 2014 11:28:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wq2yI7Mg3kkvpWnHgAT8FHPOdgpYoTIHDV6AwEXNgyE=; b=Op6wb6AIt51UGM4MZmEWonSufQnUskMjBF16iNtbAGUHQTY8XbMpZgCy5RFHqQGhPM TbCX0XWR3Wjh0b0XWbjp0MmDjmb1MawxouMo6HZJssS3BPmhStMgVIhkCUwoG3dAkQkX xg2QND58t+/4ai38H33yoCUazpi5b5RYVMUEBXWbpXy6kF6TZh4Lk10mFp1xTgPSUFnK k9kQTFzj59RdWSV/JZw6l0EqSCuB0YVZLxOBhBUIvvgxuq0xsuHzTPKL4zX8tivY4EKT JuXy5/K1BVzv4CUUoIO0Y6Z0ee3IzGe+f5nH3Rg1xyllbN7G9aZY6ZZ12iIgk5Ip+YlR Sn8g== MIME-Version: 1.0 X-Received: by 10.152.19.225 with SMTP id i1mr57429662lae.21.1412188139268; Wed, 01 Oct 2014 11:28:59 -0700 (PDT) Received: by 10.25.15.96 with HTTP; Wed, 1 Oct 2014 11:28:59 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Oct 2014 11:28:59 -0700 Message-ID: Subject: Re: ixgbe IXGBE_LEGACY_TX breaks build (patch/fix included) From: Nick Rogers To: Nick Rogers Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , Adrian Chadd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 18:29:02 -0000 On Wed, Sep 17, 2014 at 8:17 AM, Nick Rogers wrote: > > > On Tue, Aug 26, 2014 at 4:16 PM, Nick Rogers wrote: > >> >> >> >> On Tue, Aug 26, 2014 at 3:36 PM, Adrian Chadd 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 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" >>> >> >> >