The changes to the Intel ethernet drivers look fine to me.

Is this going to be MFC'd into stable/10 and/or stable/11?

In D13833#290191, @erj wrote:

Why didn't they provide a calloc(), to follow the malloc()/free() pattern?

(It looks like this was introduced in rS327674)

Why didn't they provide a calloc(), to follow the malloc()/free() pattern?

In D7802#284240, @sbruno wrote:

@erj Do you want to abandon this review in light of your work on newer releases?

We don't have anything for the Ice Lake hardware, but the Cannon Lake stuff looks like it's good.

Committed in rS327031.

I'm working on this on a github branch here:

I guess formally recognize the current state the patch is in.

In D12101#251426, @johalun0_gmail.com wrote:

In D12101#251279, @johalun0_gmail.com wrote:

The busy waiting would cause 10% CPU usage on my system when no cable connected to em0 (traced to em_if_update_admin_status).
This patch also fixes this. I can no longer detect any unusual CPU usage.

Getting a lot of witness output. Like a few per second or so.

In D12101#251145, @kmacy wrote:

In D12101#251141, @erj wrote:

Can we also get a description of what this fixes, for future reference?

Two problems:

• As we've discussed at length elsewhere, Intel drivers will busy wait for arbitrary lengths of time with a default mutex held when waiting for the firmware to release a resource.
• There is a lot of mostly duplicated code with tiny (dubious) variations.

Can we also get a description of what this fixes, for future reference?

In D11969#248501, @gallatin wrote:

Can you remind me what lock is held?

In D11378#247048, @sbruno wrote:

@erj are you going to commit this once you've made the IXL updates required for it to function?

In D11378#243549, @bartosz.sobczak_intel.com wrote:

In D11378#242202, @sbruno wrote:

I don't think these are very significant, but I get the following warnings during a build:

/home/sbruno/bsd/fbsd_head/sys/modules/ixl/iw_ixl/../../../dev/ixl/iwarp/iw_ixl_utils.c:943:46: warning: taking address of packed member 'ip6_dst' of class or structure 'ip6_hdr' may result in an unaligned pointer value [-Waddress-of-packed-member]
                i40iw_copy_ip_ntohl(loc_addr, (__be32 *) & ip6h->ip6_dst);
                                                           ^~~~~~~~~~~~~
/home/sbruno/bsd/fbsd_head/sys/modules/ixl/iw_ixl/../../../dev/ixl/iwarp/iw_ixl_utils.c:944:46: warning: taking address of packed member 'ip6_src' of class or structure 'ip6_hdr' may result in an unaligned pointer value [-Waddress-of-packed-member]
                i40iw_copy_ip_ntohl(rem_addr, (__be32 *) & ip6h->ip6_src);
                                                           ^~~~~~~~~~~~~
/home/sbruno/bsd/fbsd_head/sys/modules/ixl/iw_ixl/../../../dev/ixl/iwarp/iw_ixl_cm.c:488:36: warning: taking address of packed member 'ip6_src' of class or structure 'ip6_hdr' may result in an unaligned pointer value [-Waddress-of-packed-member]
                i40iw_copy_ip_htonl((__be32 *) & ip6h->ip6_src,
                                                 ^~~~~~~~~~~~~
/home/sbruno/bsd/fbsd_head/sys/modules/ixl/iw_ixl/../../../dev/ixl/iwarp/iw_ixl_cm.c:490:36: warning: taking address of packed member 'ip6_dst' of class or structure 'ip6_hdr' may result in an unaligned pointer value [-Waddress-of-packed-member]
                i40iw_copy_ip_htonl((__be32 *) & ip6h->ip6_dst,
                                                 ^~~~~~~~~~~~~
/home/sbruno/bsd/fbsd_head/sys/modules/ixl/iw_ixl/../../../dev/ixl/iwarp/iw_ixl_cm.c:3046:22: warning: taking address of packed member 'ip6_dst' of class or structure 'ip6_hdr' may result in an unaligned pointer value [-Waddress-of-packed-member]
                                    (__be32 *) & ip6h->ip6_dst);
                                                 ^~~~~~~~~~~~~
/home/sbruno/bsd/fbsd_head/sys/modules/ixl/iw_ixl/../../../dev/ixl/iwarp/iw_ixl_cm.c:3048:22: warning: taking address of packed member 'ip6_src' of class or structure 'ip6_hdr' may result in an unaligned pointer value [-Waddress-of-packed-member]
                                    (__be32 *) & ip6h->ip6_src);

Indeed, I don't find it too significant. I guess this is just a performance issue, which is insignificant given the amount of times this operation is done. And what is more important, this is related to the path which would be exercised only when using ipv6. The ipv6 is currently not supported, and there are some changes to the OFED going to be needed to make it work.
I may probably get rid of these warnings if it was really needed.

@sbruno - I think Bartosz needed an update to the in-kernel ixl(4) for this to work properly.

With the answer from @sbruno, I approve of the change to em(4).

This should be abandoned, right?

This probably needs to be regenerated right? Or is it going to be dropped due to the upcoming conversion to iflib?

There's still only one entry before the patch. But this looks more correct.

@rlibby , after reading the linked bug report, I think it would be a good idea to go the extern route. Could you regenerate the patch and define ixl_bcast_addr and ixl_fc_string in ixl_pf_main.c? (The latter would only ever get used in the PF driver; only the PF driver uses the former). Or just commit everything but the changes to those two, and I could make those changes.

Is gcc requiring the additional const keywords?

I should add that we're going to update the ixl(4) driver soon because as @bartosz.sobczak_intel.com mentioned, it will fix a crash.

I've decided against bumping the FreeBSD version number -- there aren't very many defines added here, so adding #ifdef's isn't too big of a deal.

Remove ixgbe updates.

• Add NOINTEL config file for testing
• iflib: Update with style(9) fixes.
• ixl(4): Begin process of converting ixl(4) to use iflib.
• ixl: Copy over final bits of D5214 diff, possibly break some stuff.
• ixl: Add more files.
• ixl(4): Fix a lot of compile errors
• ixl: ixl pf driver seems to compile ok now
• Mostly compiles; start to remove legacy code...
• ixl(4): Driver is iflib-only; compiles but causes kernel panic at attach.
• ixl(4): PF driver compiles and ping works.
• ixl(4): Remove comments; make queue interrupts RX-caused only
• ixl(4): Edit comments
• ixl: Get rid of files accidentally re-added during rebase.
• ixl: Fix compile error
• ixlv: Start converting driver
• ixl: Update to 1.7.12; fix compile.
• ixl: Change name to 700 series from just 7
• ixlv: Convert more of driver
• ixlv: VF driver still not fully converted, but now compiling
• ixl: Bug fixes; label formatting in iflib
• ixl: Fix bug where tx would stop working after ifconfig down && up
• ixl: Random changes
• ixl: Somehow fixed weird TXQ 0 bug supposedly fixed a couple commits ago
• ixl: Change TODO comment from question to must-do
• ixl: Start changes to support HW TX interrupts in iflib (like in legacy driver)
• ixl: Fixes to get ixl building again, after iflib update.
• ixl: Remove various comments and printfs
• ixl: Updates.
• ixl: Update reset handling; make some iflib functions non-static.

I kind of want to bump __FreeBSD_version to make it easier for our drivers to see if there's support for these new media types.

@sbruno is it ok to remove "first" in igb_txrx.c? It looks like it might be a leftover from the pre-iflib converted version of the driver, but I don't know if it was intended to be used for something in the current version.

Better to MFC to 1.7.12 now...

In D9851#204961, @smh wrote:

Massive amounts of changes in this so impossible to see if everything is good, however a number of style related bits highlighted, some of which are regressions.

Committed in rS313497.

ixl: Fix compile error

Remove old D5213 files.

ixl: Get rid of files accidentally re-added during rebase.

Convert ixl-1.6.6-k (or at least the PF-non-IOV driver) to iflib

I'm going to wait for Jeff's team to give the okay before I commit it. I don't want to break more than I have to. :v

• Add opt_ixl.h to ixlv Makefile for build
• Add comment describing IXL_IW to GENERIC config
• Default to disabling the iWARP client interface by setting tunable to 0

I can attempt to update the iflib version of ixl with what he have internally, but would it be a better idea to base it off what's in the iflib version of ixgbe right now (D5213)?

This matches the existing method for accessing fields in the rest of the if_t api, so I'm okay with it.

I was late to commenting on it, but it looked fine to me. It looks like it's similar to the ixgbe code.

I agree with @emaste's request for a comment.

In D7802#163541, @jeffrey.e.pieper_intel.com wrote:

arc is failing to apply this, as it is trying to apply it to stable/10/sys/dev/ixl, but SHOULD be sys/dev/ixl. I had to apply it manually.

In D7802#162125, @sbruno wrote:

Which svn revisions is this going to MFC?

Did you have to change much from the original code for this MFC?

Do arc command from repository root.

I don't think the changelist looks right; this is supposed to apply to stable/10 and have mergeinfo, I think...