Remove the drain limit completely and instead try to fill the TX queue on each drain.

In D18532#395386, @olivier wrote:

tx_abdicate still brings lot's major gain against D18532.
Theory invalided ?

I didn't think this code was still in use... AFAIK, ixgbe uses the iflib netmap support now.

In D17979#384108, @pkelsey wrote:

Style-wise, would it be better to set up an sctx local at the top of these routines and then dereference that to avoid the double-dereference noise in the code?

Address feedback.

Does not address the issue.

Restore setting ip_csum to zero for TSO when IFLIB_TSO_INIT_IP is set.

There is an upcoming patch that will make the IXL_CSUM_IPV4 macro obsolete, but better to fix it at both ends anyway.

In D17881#382102, @lev wrote:

It fix ix0 for me.

Move setting CSUM_IP_TCP into the correct block. Also set CSUM_IP.

Add missing semi-colon.

Add gtaskqueue_drain_locked() to hold common code for gtaskqueue_drain()
and grouptask_block().

My opinion is that mtx_owned() would just make this all more complex. Releasing a lock for a short period isn't a problem at all.

iflib_admin_intr_deferred() called with STATE_LOCK() in a few places.

Hrm, I don't think we can obtain CTX_LOCK() in those functions.

In D17404#371990, @erj wrote:

In D17404#371923, @shurd wrote:

Is there a reason not to do this in taskqgroup_detach()?

I don't see any obvious thing which prevents something being enqueued between the gtaskqueue_drain() and taskqgroup_detach() calls.

For the latter statement, should iflib_admin_intr_deferred() then add a check to see if iflib is in detach before calling GROUPTASK_ENQUEUE()? I don't see other places where it's enqueued.

"Abandoning" because I put the wrong URL in the commit message.

Bah, sorry... looks like I just grabbed whatever URL I had open at the time. :(

Is there a reason not to do this in taskqgroup_detach()?

In D17393#371122, @lev wrote:

This patch (first version) breaks my I210 completely.

Explicitly set E1000_TXD_POPTS_TXSM when setting the checksum type.

Remove trailing semicolon while we're here.

In D16882#361193, @gallatin wrote:

Sorry, having the ring pointer in the ring is just so odd.. Can you explain why it is there? Maybe it would be better to just not have the ring pointer in the ring and not have to have all these special cases.

I'm fighting an iflib bug myself, and every time I have to dig into the code, i'm irritated at what seems to be complexity driven by premature optimization...

In D16882#361076, @gallatin wrote:

What keeps the normal, non-IFC_QFLUSH from hitting this condition? Is the txq pointer included in r->size?

mp_ring->items is void *, not struct mbuf *.

Fix test for txq, and cast to the appropriate type before comparison

Run through igor and mandoc -Tlint

Remove iflib.c patch.

Fix builds on GCC targets

Looking at iflib_txq_drain_free() more, we likely want to just extract the free loop and put it in a LINK_ACTIVE() block in iflib_txq_drain.

Possibly the easiest way to ensure we don't enter the STALLED state while link is down is to have iflib_link_state_change() set txq->ift_br->drain = iflib_txq_drain_free when link goes down, and then txq->ift_br->drain = iflib_txq_can_drain when it comes back up... which would mean stopping and resetting the callout timer on link changes.

In D16875#359599, @erj wrote:

The in-tree igb never sets IFLIB_ADMIN_ALWAYS_RUN. Is this for a modified version of igb?

Address feedback.

Add Sean since he's being asked to setup a test system.

Aside from the VLAN_XUNLOCK() on return at at 1366, the rest are comment churn.

Remove bnxt.4 changes from review.