Could make the flags bool instead of int but for the sake of minimal change for now, on a quick pass it looks ok.

I'd be happy with this. I'd still think there could be a comment saying "If each (vnet) jail would also have a unique hostuuid this would not be necessary." for the getjailname() call.

I've started on the inevitable try to rewrite epair(4) two weeks ago (need to say it's UBR work) and ridden it of the netisr.
I do have a prototype which seems working; need to figure out how to scale things up to hundreds of epairs or 100(s) of CPU threads.

In D24383#536488, @kp wrote:

In D24383#536382, @bz wrote:

(1) can we stop assigning locally administered addresses. We have general infrastructure in the FreeBSD OUI. Or is there a reason we cannot do that?

We can, and if_bridge does so, if hostid == 0 (which is the case for jails not created with host=inherit). I'm not clear on why the bridge has these two approaches. We could simplify the code by removing that, and just always calling ether_gen_addr().

(1) can we stop assigning locally administered addresses. We have general infrastructure in the FreeBSD OUI. Or is there a reason we cannot do that?
(2) jails have a hostid as well. If they are the same for all of them then maybe we should fix the the jail code to make sure they actually are unique if not set?

I like the idea; I'll wait for the sbuf conversion.

Fix more errors of in-between work.
I should really write that test case which would be simple.

Correct logic bug identified by gert.
Factor out the code into its own function as requested my @melifaro.

Actually check that PRUS_IPV6 is set before accepting the IPv6
control message in IPv4 lands.

... and on my arm64 boards for 66 days or shorter. Updated to the latest version a few days ago. So far no issues either.

In D22003#528176, @melifaro wrote:

@bz: do I understand correctly that you're okay with the patch but suggesting committing the exact same change but in 2 separate commits?
Both referencing this review, one for if_ether.c and another for nd6.c?

ping6? Or else it goes in... which I don't know if it's the best idea ...

Update (move sysctls to the top of the file).
Implement excluding dr pref updates from the resource limits as suggested by @melifaro.

I am re-opening this again as HPTS still needs fixing @rrs . See https://reviews.freebsd.org/D23726?id=68452 for the original diff.

In D23886#525168, @olivier wrote:

In D23886#525161, @bz wrote:

@olivier do you have a non-forwarding TCP test-bed these days?

I have a nginx <=> wrk lab, do you think we could use it in this case ? By serving only very small files, like 16Kb and asking wrk to use large number of clients, something like 2500 or more ?

@olivier do you have a non-forwarding TCP test-bed these days?

I re-run UDP6, min-size packets, pps tests on a multi-user system for all four cases (1-2 is the patched new KPI use when possible, 3-4 is the vanilla kernel runs):

Not my expertise of code but looks ok to me.

In D23872#524865, @ae wrote:

This code, probably, was written with hope of depreciation of scope embedding into addresses.

Update based on @ae 's comments.

I'd probably still commit the nd6 change separately.

Can someone look at the hpts bits please? I know they are not as straight forward as is the ktls case.

add myself to keep track of it

Anyone else any comments?

Anyone any comment on this? Otherwise I'll commit it the next two days.

@gallatin I hope this makes sense ..

Seems all sorted now. Thanks especially to @gallatin for bearing with me.

Pass the proper csum flags into the 2nd call of ip6_output_delayed_csum().

Add KASSERT as suggested by @markj .
Remove hlen variable which always matches unfragpartlen as suggested by @markj.
Fix a case where we possibly do not update the ip6 pointer.
Leave a comment about an unclear header clearing line for future contemplation (which was removed in the previous revision).

Leave comments and questions (and another possible bugfix comment for later).

In D23760#521993, @gallatin wrote:

I'm 1/2 joking, but what would you think about not supporting extension headers at all? They are the worst part of IPv6 and make everything complicated and add lots of hairy cases. What benefit are they?
(I'm legitimately curious)

Correct changes based on the comments from @markj and make hdrsplit
a bool as it is used as such.