Attempt to fix paths for stable/11.

• Replace a space after #define with tab

• ifconfig: Add option to report VF status info
• ixl: Add a license to ifvfstatus.c
• ixl: Updates to if_ixl.c
• Add spare data fields to struct ifvfstatus

Anyone else have any feedback? It makes sense to me that the attach process for pseudo devices should use the context lock like the attach process for regular devices.

Should this revision get closed? Nothing's happened on it for months.

Does this match what the Linux PF driver does?

@piotr.pietruszewski_intel.com Are we going to abandon this for now?

In D19041#407181, @marius wrote:

Well, I would just have went with "PCI" but if you prefer to state all variants :)

Would it be a good idea to group the iflib drivers together in the config files, so it's obvious there?

In D18402#392608, @v.maffione_gmail.com wrote:

You're right. I realized that just now.

I guess I could try to modify iflib_netmap_txsync and iflib_netmap_rxsync.
This patch could still be useful for FreeBSD 11, where ixgbe does not use iflib (as far as I see from the code).

Having an invalid value for the head writeback value is problematic...I'll check out the PR.

@jeffrey.e.pieper_intel.com you should re-test this, now that Piotr has updated the patch.

Ensure that iflib(4) and associated drivers pass correct RIDs to bus_release_resource(9) by obtaining the RIDs via rman_get_rid(9) on the corresponding resources instead of using the RIDs initially passed to bus_alloc_resource_any(9) as the latter function may change those RIDs. Solely bnxt(4) was using the correct RIDs by caching the ones returned by bus_alloc_resource_any(9).

Should I be the one to commit this, then?

Does anyone on this review know why this is necessary on 12.0+? I think we were supposed to be doing this in the first place, but I don't know why this stopped working.

The description should mention that this also affects/fixes ixv(4), too.

I'll commit this for Jake and try to get it into 12-RELEASE

@krzysztof.galazka_intel.com I think @shurd's version here is better in that it masks isc_capabilities before togging RXCSUM/RXCSUM_IPV6. Though I think if you had added that, they might be roughly similar.

Looks like it does what it's supposed to.

In D17404#375201, @krzysztof.galazka_intel.com wrote:

In D17404#373883, @shurd wrote:

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

I've moved STATE_UNLOCK before iflib_admin_intr_defereed call although releasing lock just to immediately grab it again makes me a bit uneasy. Maybe it would be better idea to use mtx_owned in iflib_in_detach to check if this lock is already aquired?

Err, "arc patch" doesn't apply this cleanly to my svn tree -- it complains that it can't find the new files if_iavf.c, iavf_vc.c, and iavf.h to patch.

In D17544#374994, @sbruno wrote:

@erj do you want to ask RE permission to commit this?

My only nitpick is that ixlvc.c should probably be renamed to iavf_vc.c instead; it's supposed to contain the functions that communicate via the PF<->VF virtchannel.

Any last-minute assents or objections?

I'm going to try to get these committed, soon; I don't have any more planned changes.

@krzysztof.galazka_intel.com , you need to re-upload this patch

I can't tell if this is right or not, but it looks like an ok change to me.