tuexen's inputs.

In D12430#259071, @tuexen wrote:

Shouldn't we also apply something like

 	/* Map our computed MSS into the 3-bit index. */
-	mss = min(tcp_mssopt(&sc->sc_inc), max(sc->sc_peer_mss, V_tcp_minmss));
+	mss = sc->sc_peer_mss;
 	for (i = nitems(tcp_sc_msstab) - 1; tcp_sc_msstab[i] > mss && i > 0;
 	     i--)
 		;

since we will use the computed index to restore the sc->sc_peer_mss later.

In D12453#258240, @rwatson wrote:

This seems generally sensible.

I'm not quite sure about keeping the "Non-standard RSS hash types" comment, as M_HASHTYPE_OPAQUE is basically intended to be a catch-all for any other model, and is not specifically intended to be RSS (hence not having RSS in its name). So I'd be tempted to drop that comment.

In D12450#258277, @sbruno wrote:

Did microsoft update the referenced link? I don't see the removal notice in it.

Address Hans' comment

Add comment about the network VF and hn(4) work together

In D11635#242645, @royger wrote:

Sorry for jumping out of the blue, but I don't understand what this is all about. You seem to use lagg together with VFs (I assume PCI Virtual Functions), yet there's no commit message at all explaining what's going on, I think you should add a proper commit message describing how this is supposed to work.

In D11003#242017, @kevin.bowling_kev009.com wrote:

@sepherosa_gmail.com does this look good to you now?

Consistent temp variable naming

Fix eventhandler deregister on detach path

Heh.

In D11003#233679, @johalun0_gmail.com wrote:

In D11003#232523, @sepherosa_gmail.com wrote:

And your implementation actually suffers the same issue as Linux: if any of the listen socket is closed, the sockets on the closed listen socket's accept queue are dropped; but well, that's may be acceptable, since I don't think Linux even fixed that.

Would implementing https://github.com/DragonFlyBSD/DragonFlyBSD/commit/02ad2f0b874fb0a45eb69750219f79f5e8982272 solve this?

I think you took a pretty old version of the code. I fixed the hash stability issue in a later version; you probably want to check that. And your implementation actually suffers the same issue as Linux: if any of the listen socket is closed, the sockets on the closed listen socket's accept queue are dropped; but well, that's may be acceptable, since I don't think Linux even fixed that.

In D10564#219024, @jhb wrote:

I'd kind of prefer we fix the drivers, though I think this patch is fine for now. I have an open item to refactor even the ACPI code to not use pci_cfgreg* directly but instead punt that up to the parent of acpi0 (nexus0) to support arm64 (and to support systems with multiple domains).

minor style fixes; remove unnecessary comment.

It nullifies Hyper-V hot channel effect, thus actually hurts performance. Drop it.

In D10272#213213, @jason_eggnet.com wrote:

Here's an idea from gnn that I agree with:

The fundamental issue here is that the syncookie is good enough to pass validation, but there is sufficient information in the syncache entry to reject it. The patch proposed here is a workaround for deleting the syncache entry.

I think the original problem is that we deleted the syncache entry. Why not set a flag or change the state of the syncache entry to prevent future packets from being accepted for that connection, and let the syncache expiry mechanism deal with deleting the syncache entry eventually.

Looks pretty good to me. Some minor code style suggestion.

We plan to commit this near the end of this week, if no objection comes. It detects possible errors, and obviously will not make the situation worse than before.

OK, I see. Please fix the commit message when committing then. BTW, in addition to include/dev/hyperv, there are usr.sbin/hyperv and several manpages that you probably want to manage w/ MK_HYPERV.

I don't see why it is needed. If hyperv is not in kernel or the ref rdtsc is not the current timecounter, this path will never be hit. Or do you have other concerns?

If no objection comes, we plan to commit this earlier next week.

In D8904#185970, @karels wrote:

I think the change is a step in the right direction. Certainly, "ifconfig xxN down" followed by an implicit UP should not cause any change to the routing table. Does anyone know why the "down" is removing the route? That seems wrong to me.

storvsc parts looks good to me.

See the comment, rest looks good.

In D8905#185507, @jhb wrote:

I would suggest rewording the message a bit to something like:

Defer if_up() until after the interface's if_ioctl method is called.

This ensures the interface is initialized by the interface driver before
it can be used by the rest of the system.

ship it

ship it.