Thanks for getting this in, Sean.

ixl/ixlv: Fix INET not being defined by including option headers in central ixl.h header.

In D7391#153621, @sbruno wrote:

I think we'd need a bit *more* of a commit log on this one. Any chance of getting a paragraph or two?

Trying this again with a newer version of arcanist...

Looks good.

The intel driver changes look ok to me, but what's the reason behind indicating that the hash that comes out of the card has hash properties? (I guess this might be covered in previous reviews or commit messages)

• ixl: Re-add a change to TC0 setup made in D5203.

Looks completely valid to me.

What does this warning in the log mean?

Committed in rS295947.

Committed in rS295946.

This was committed in rS295831, but this revision didn't update for some reason.

In D5211#114950, @gallatin wrote:

Hmm.. Even when loading the module at boot on -current, I'm still seeing a panic:

Build comments

Yep! I can confirm it does.

Some files in ixl in the newest diff still won't apply cleanly.

Could someone indicate what kernel build settings are necessary to get this to work? It looks like ixv needs to be excluded, and netmap needs to be removed from the kernel config file, but what else?

This doesn't cleanly apply on top of 11-current, on rS295683.

Update with no magic number and a better comment.

Firing...

In D5193#110543, @tuexen wrote:

Regarding the FreeBSD version checks for >=10:
I tried to be consistent with the rest of the file. If you want to get rid of them, that is fine, but it might make more sense to get rid of them consistently in the whole file then.

But I'll do what you suggest...

A couple notes on the patch inline, and one general comment:

You can go ahead and commit this one.

It looks good.

@gnn hasn't said anything. Would someone else like to commit this?

I'd still need to get approval from one of my mentors, right?

Going by the man page, yeah, it looks like you should use taskqueue_enqueue_fast() instead of taskqueue_enqueue() if you're using the global taskqueue_fast.

It looks like this does legitimately fix a bug; @jeffrey.e.pieper_intel.com we can work on getting this fixed internally.

Change SYSCTL_ADD_UQUADs back to SYSCTL_ADD_U64s.

The current form should be testable -- just arc patch D3162 and see if your i219 starts working. We had it working on our internal version of the code, but that's using a different version of the shared code that doesn't include anything igb-specific.

See D3162.

Mostly gave up on trying to split this up into separate commits -- this patch is a combo of ~94 commits to three repositories, and I don't think it would be a good idea to waste more of the community's time trying to get this split up.

I haven't compile or functional tested, but the contents of the diff look good. It's a good idea to split out the actual setting of the advertised speed and flow control settings from the sysctl stuff.

I think I recall you saying that he ended up getting his i210 working again? But I can't remember if it's with the new igb code or he got the reverted version working again. I'll reply to the thread.

Quick re-open until I get an answer to the last comment.

Before I update D3162, was Oliver Hartmann's (or someone else's) original issue with the i210 solved? I remember hearing from you that it was, and we still can't find a problem with i210 using the code that's in D3162, but I wanted to make sure we knew what the actual problem was.

Update incoming...