Taking glebius' requested style changes.

In D58597#1345174, @kevans wrote:

In D58597#1344902, @bms wrote:

This is directly in the line of fire of my GSoC student's MPLS work.

This should be pretty easy to rebase around, at least.

This is directly in the line of fire of my GSoC student's MPLS work.

OK, so the parent revision got pushed by me accidentally already. Squashing at this point is probably out the question.

In D58590#1344748, @glebius wrote:

Can you please just squash this revision into D58585? It is a straight one liner bug fix of it.

In D58585#1344817, @pouria wrote:

Nice work, do you have plan to create an I-D for it?

In D58588#1344732, @glebius wrote:

Makes sense to wait for jhb@ for a few days.

@glebius "In lieu of" is typically taken to mean "instead of", "in place of", "with respect to". I was hoping to delegate Kyua-ifying the test to another volunteer so I can defer having to deal with Kyua upfront right now and keep the momentum, but if you insist, I guess we will have to do it that way. Can we at least land the other revisions before I proceed with that? I would in any case have to get familiar with Kyua anyway for landing other code. There's one big ball of otherwise unrelated wax which might be better done in Open vSwitch, but I'm still meditating on it.

I think this is a wrap.

In actual fact, https://reviews.freebsd.org/D58591 was informative, but the swizzle was happening in the *wrong place*.

Good catch, this was being munged elsewhere. The ntohl() for the 0x0000FFFF component is definitely needed.

Root cause analysis revealed 2 kernel-space issues:

Root cause analysis revealed 1 user-space issue:

In D58588#1344538, @pouria wrote:

I'm not sure whether they can be static or not, but the naming is definitely not right.

Mend and make do.

Address all review comments, caveat the addition in the HISTORY section.

The #ifdef INVARIANTS conditional for _Static_assert() is mostly a no-op, because GENERIC enables them via "include "std.debug"".

This change has been exercised with bird3. And the tcpdump dissector I forgot I wrote almost ~22.25 years to the day...

Compile tested for amd64 GENERIC.
The next Differential will contain the netipsec/xform_tcp.c refactoring to use ip6_hdr_pseudo{}.

Inlined as glebius requested, but this counter-intuitively adds more
churn as declarations then need to be moved further up in the
translation unit.

Incorporating Gleb's requested changes.

a number of these are things I introduced, no objection

+1 for utility.

The rationale is pretty clear. Whilst it would be preferable to be default-deny (for much the same reasons as security models built on top of this are also default-deny) it cannot be so for compatibility reasons (yet; perhaps in future).

In D56750#1313882, @pouria wrote:

The reason was BIRD, I saw @melifaro's commits on it and learned he wanted FreeBSD's netlink to remain as close to Linux's version as possible.
Please keep this review open if possible. the use case will come up soon, though I don't know exactly when or for what.

Ah. This more or less removes an item from my TODO list. Thank you. The intent was always to profile first, add Minshall later.

This makes things nice and clean for SRv6 in future, if and when that happens. Thank you.

I have plans to add Delayed ACK profiling eventually, does this collide with anything, or is someone going to beat me to it?

This is giving me 2003 flashbacks.

Surely the point is moot though and SSRR/LSSR accepted only for feature-completeness in IPv4? E.g. SR-MPLS and SRv6 do not use it.

Yeah let's get stinko!

In D56947#1304518, @glebius wrote:

In the commit text, in the phrase it'll drop packets from the queue but fail to remove them, I'd suggest to change drop to free or m_freem.

I concur that commit-id 855239e56 of xnu/bsd/netinet/igmp.c from https://github.com/apple-oss-distributions/xnu appears to have a similar fix, but they explicitly split the conditional further. The "fog of war" of xnu imports in "git log" prevents further instrumentation beyond the obvious "git blame" "where the bodies are buried" action. (Hey, I had a git sparse-checkout lying around in my primary FreeBSD VM dev instance. Go ME! But that was also part of the ongoing xnu dissection, "Take what is useful, destroy the rest." Developer Hegemony is currently looking like a bit of a pipe dream, unless people start taking what Dijkstra said in 1975 about "complexity generators" seriously.)
Gotta go, I'm out of actual food, so I need to go to the shop, respond to my other GSoC student meaningfully, and tune in to "Auntie" (Prof.) Emily Bender at 2000BST on Twitch.
UPDATE: OK, that was not as cool as I thought it would be, and I've eaten too many crisps and cheap sushi. She was mostly poking fun at people's huge AGENTS.md files on GitHub.

Yeah. Don't have much to offer here, I'm afraid, ironic being the instigator, but just so much is going on at the moment, and I'm literally RAMMED every DAY. The mental map of this code is long gone from the forebrain, but probably lingers somewhere, but I'm not about to pop Piracetam or Choline Inositol to find out this week. (Those are nootropics; the latter are nutraceuticals.)

Testing any of it outside of simulation might be difficult. I left my Madge 10BASE-T/ATM25 dual-mode switch behind in Berkeley in 2005...

Userland impact believed non-existent, these are kernel-space structures and are not generally exposed outside of in_mcast.c/in6_mcast.c.

LGTM with caveats. any plans for a Kyua test to catch the strafe fire in the ISN space this looks like it should close against?

Just fired up one of my Haswell-based Dell Optiplex 3020 test boxes... and there's no DEBUG for their onboard Intel C200 xHCI.

Just fired up one of my Haswell-based Dell Optiplex 3020 test boxes... and there's no DEBUG for their onboard Intel C200 xHCI. So, I cannot even test any of it any more.

@markj has been working to make MROUTING multi-FIB.

In D55631#1285161, @kevlo wrote:

In D55631#1284650, @bms wrote:

I was able to obtain an axge(4) compatible USB3 adapter for ~6GBP from Amazon.

Is the chipset ax88279? If so, could you send me the link to the product so
I can buy one? Thanks.

OT: I have an item to look at TCP_QUICKACK like Nagle suggested as per my DevSummit workplan

In D56115#1284434, @iyan005_outlook.com wrote:

So we've seen functions grow new errors over time, or some implementations return other errors for reasons that were consistent with the standard, but maybe not one of the ones listed.

Yeah that makes a lot of sense, best to be future proof.

+1 for doing this, but I have not reviewed code (yet).

I was able to obtain an axge(4) compatible USB3 adapter for ~6GBP from Amazon.

TL;DR Not functional under KVM passthrough of either ThinkPad P14s xHCI node.