Cool, surprised this wasn't caught earlier :)

Thanks for getting this in Eric.

The block of code that Sean asked about is basically something the hardware
team said needed to be added, they gave me no details, this is often the way
it goes Sean, sorry :)

Code got added because Jeff saw link changes not being visible in a VM,
I do not recall for sure if he tested a desk build, but things are certainly
broken without the code... so long as you've done basic sanity testing I
would commit it.

Integrated in r283883

The shared code changes just require some legal stuff if they are taken back into our code base, if you leave it as is we can cope with that later, its not like the E1000 shared code has a lot of churn at this point.

Thanks for all the work you put into this Sean, go for it :)

We removed these additional task creations with the intent purpose of
reducing lock contention for a customer as I recall, so unless you have a
good reason to add it back I would oppose doing so.

Correct a couple minor points in the last revision.

Remove x550 device that is not yet available. Also remove unneeded shared code prototype,
and some added whitespace.

Looks good, thanks much John!

Change E1000_MRQC_ENABLE_RSS_4Q to E1000_MRQC_ENABLE_RSS_8Q, and the comment
to :

The code is not acceptable as is right now, Eric and I are discussing changes.

Looks good.

can't wait to see the infrastructure in place :)

Looks good. Again, will need real world testing when we have infrastructure.

No problems

No issues.

Good.

Don't see any problems.

Let's not mention Linux in our comments, either say nothing or think of something else :)

seems fine

Fine

Don't see any issues, of course the proof will come in the actual use when we
have the infrastructure :)

See no problems.

In D1580#6, @jhb wrote:

Can you provide more details on why you need to separate them (and why you need to rename them)? Note that a single kld can contain multiple drivers (like if_lem.c and if_em.c in if_em.ko).

I do think having the kld name match the interface is good (so the ifconfig auto-load magic works), but it's not clear to me why you can't just include the VF driver in the PF driver's module? (And renaming options in a kernel config is pretty disruptive, so there need to be good reasons.. People are probably still somewhat burned over emX devices changing to igbX at one point.)

Thanks Ryan, am happier with this.

Changes in my code are trivial, and fine by me.