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...

This keeps on getting pushed back.

Ok, will do. I wish there was a nice way to lump a bunch of diffs together into one revision in Phabricator, though.

Did not re-using context descriptors work out for you, and you don't see the wrong queue value in the receive descriptor?

Oh geez, I didn't realize Arcanist would grab the commit messages and commits from my local tree automatically. Hrm.

Regenerate if_igb.[ch] changes, hopefully without the extra commits.

In D3165#71223, @sbruno wrote:

This update seems to fail to apply at all. I get numerous errors about patches being already applied. Can you regenerate against a clean checkout?

In D3162#70947, @sbruno wrote:

restore 'max_frame_size' for em(4) lem(4) devices

Add additional arguments to calls to e1000_set_eee_i350/i354 that I
just grabbed from linux. Is TRUE valid? I have no idea.

• Added includes to start of if_igb.h that were mistakenly left out in the initial diff.

Those numbers don't look abysmal, I think. Try it without TSO, and if the numbers don't noticeably get better, then maybe your new limit of 64 is okay. I would also try to find out the largest nsegs value after DMA mapping in xmit() (printing it out or using DTrace) so we could try to find the longest chain it tries to send.

! In D3192#65249, @sbruno wrote:

hrm ... "-m" ?

Then it's possible the hw max isn't 32. I've read several e1000 device datasheets and haven't seen a mention of the max # of buffers device can handle, so I don't really know what it could be. Maybe it's similar to ixgbe, and the actual hw can handle 40?

I'm looking at this, but I don't think it's a high priority right now.

In D3161#63342, @sbruno wrote:

In D3161#63337, @sbruno wrote:

https://svnweb.freebsd.org/base/head/sys/dev/e1000/e1000_82543.c?revision=200528&view=markup

Hrm ... jack seems to have a documented customer report of this fixing something. Or am I mistaken?

The issue is I don't know what it fixes. It looks the generic read_mac_addr reads registers to get the MAC address instead of reading the NVM like in the 82543 one he added. Normally, at least for the devices I know of, the device loads the MAC address from the NVM into the registers so you don't have to do an NVM access to get to them. Maybe it was/is broken for 82543?

Maybe there was a large number of machines that were sent out with identical MAC addresses, hence the flipping of the bit in the address on the 2nd NIC

In D3161#63325, @sbruno wrote:

Hrm ... these two function appear to be setting mac->ops.read_mac_addr

Is this populated via another method?

Would like feedback from someone who owns these to see if this negatively affects them. I didn't see them in the current version of the shared code, so I wonder if whatever problem these fixed was fixed somewhere else.

Update copyright in license header in every file to 2015.

In with r285768.

Thanks for making these tunable/sysctl fixes to ixgbe.

Fix indentation and add parentheses around validate_mac_addr() check.

I have no objections now, but this could end up getting changed in the future.

Comments inline, but it's fine as-is.

In D2922#57481, @pkelsey wrote:

In D2922#57477, @erj wrote:

Everything but the change in ixgbe_vf.c looks good to me.

It looks like the PF driver needs to not set CTS when it acks the reset request, instead of the VF driver ignoring the flag.

So ixgbe_vf_reset_msg() in if_ix.c needs to change instead.

It certainly wasn't clear to me what the implementation intent was with CTS flag, so I made this change in what appeared to be the most consistent way given the existing code. In this case, ixgbe_set_rar_vf(), ixgbe_set_uc_addr_vf(), and ixgbev_get_queues() served as the reference for what the VF side of things was doing before checking flags in the response header. Considering your requested change to the patch, would those also be changed under the same reasoning? Also, in if_ix.c, ixgbe_vf_get_queues() is setting IXGBE_VT_MSGTYPE_CTS in its response - should that also be eliminated as the receiver of that response is just masking it off?

Everything but the change in ixgbe_vf.c looks good to me.

Or, it turns out I already made the changes. They were committed as part of r284049. Enjoy your 40G KR4 connections, if you have those.

This has already been committed, likely as part of r284049.

I still need to do this...

Like @D2050, this hasn't made it in yet. Does this need more work or testing?

Bump -- it looks like this hasn't made it in yet. Does it require further testing, or...?

Alright, it's fine to leave the defines in e1000_defines.h. With the MSI-X comments being changed, this is ok with me.

Aren't all the comments saying MSI-X is disabled when EM_MULTIQUEUE is enabled are wrong now? I was under the impression that with the changes you've made, you should use MSI-X when using EM_MULTIQUEUE.

@jfv says that section was taken out to reduce lock contention.

I'm hesitant to approve this because the if (more) {...} section was removed in r251964. I'd want a reason for putting it back in the driver.

Looks reasonable.

It looks like the feedback I'm getting both internally and here is that this switch statement is pretty confusing. The intent is to let each media type option advertise its full speed as well as all the slower speeds it can; I arrange the media types and omit some break statements to make it work in a switch statement. So, if you look at IFM_10G_T, it will advertise 100M, fall through to the IFM_10G_CX4 case and add 1G, and fall through to the IFM_10G_TWINAX case and add 10G, and then break.

Made changes suggested by @adrian and changed the copyright to 2015 in all the files.

The man page / README needs updating, to describe the new sysctls and functionality.

I'd want to wait for a comment from Jack, but this looks good just by looking at it.

In D1149#31, @alfredperlstein wrote:

This is not the case.

Having to load a module to get around the fact that TUNABLES are read too early in the device drivers is not the right way to do it.

It breaks netbooting for one.

It disallows making a kernel module to set some auto tuning.

This should stay open until someone comes up with a real solution for setting tunables after loader, but before device driver initialization.

If you don't understand then that's fine, contact me offline and we can arrange a call to explain the need and why you would want to fix this.

Yep, you fixed it. Thanks!

Err wait, I think you mean to remove the assignment to more on 1201, and not the call to ixgbe_rxeof(), too?