Do you plan to rebase that over removal of IFP_TO_IA() in preference to in_ifprimaryaddr()?

P.S. I would suggest to retitle to netinet: introduce in_ifprimaryaddr() to lookup first IPv4 address of an ifnet. IMHO, there is not reason to reference a macro that is about to go away.

I added some suggestion, but they are IMHOs. I'd suggest to wait for approval from a doc committer. @ziaee maybe you?

In D48709#1269030, @pouria wrote:

Are you still working on this? @glebius
if that's the case, Could you please set the planned change state for this revision?

I'd suggest to change to title to explictily say "TCP over UDP", cause "TCP/UDP" can be misinterpreted to a change to TCP and a similar change to UDP.

LGTM module suggestions made in D55344.

I agree that not much left of ifcreate_nl() and it can be inlined into ifgeneve.c.

The ndq_refcount seems to be not really used. Could it be you wanted to use to to have the callout to refcount the ndq?

Immediately caught in bridge(4):

NET_EPOCH_ENTER(et);

Sorry for making the Geneve check-in process longer, but I really want to understand all corner cases, instead of workarounding them.

No objection for MFC. Neither encouragement, though :)

Not an expert in the area, but code wise LGTM.

In D55174#1263726, @pouria wrote:

After running my tests for this change, I remembered that
the netlink can reply with an NLMSG_ERROR containing error = 0.

I'd suggest to commit all comments and whitespace changes that can be committed without breaking down nd6_ra_input() separately. That will make meaningful diff smaller. btw, it is great putting references to RFC before important actions and checks!

Sorry, missed the if (nbio == 0)

Can you please rebase? There is no longer ND_IFINFO().

Also (NETLINK) isn't a great error message at all. Please try grep errx sbin/ifconfig/*.c to check other error messages. Maybe just only contents of errmsg.error_str in the case it was provided and unknown error from netlink(4) in case it was not?

No objections from me, I rather agree. But I am not enough expert in IPv6 to make a strong judgement on defaults change.

Merge this original diff + Warner's D55107 together.

Sorry, I didn't ask to de-virtualize the queue, only the lock. I actually asked why can't we hang off the queue from the in6_ifaddr instead of making it global? btw, how many queue entries per unique address could be there?

Approved, but please address comment in the module event switch statement.

Please consider all trivial MFCs approved.

I can't understand the problem. If structure is known sizeof(*ext) results in the same value as sizeof(struct HDB_extension). If the structure is not known and has only forward declaration, compilation should fail with: invalid application of 'sizeof' to an incomplete type.

For such a test you'd better move one of the interfaces into VIMAGE jail. This will isolate not only from this particular problem, but from other potential problems.

What about ordering the zfsinfo? If (pd->pd_handle == boot_img->DeviceHandle) add entry to head, otherwise add it to the tail.

In D55064#1258692, @zlei wrote:

Is bpf_chkdir() dereferencing a NULL d->bd_bif in net epoch ?

and if they do I believe they deserve to go on a treasure hunt

Oops, sorry. If the reviews.freebsd.org mailbox was open in mutt while I was fixing the test, then I would not jump in front of you.

Oh, sorry for that. Let it be then -fms-extensions until -fms-anonymous-structs hits our version of clang. But for the files that need it.

First, let's talk about -fms-anonymous-structs then instead of -fms-extensions, cause the latter enables much more. Second, please don't use the fact that I added this flag back in 2015 for gcc as an argument. Gcc is our second tier compiler and back then this change was the least intrusive hack to allow us to go forward with C11 feature and still be compilable by back-then version of gcc. Actually, I should look if this change can be reverted today. Finally, the list of files you provided doesn't look scary to me. It is 12 modules out of more than 500.

In D54986#1258395, @bz wrote:

In D54986#1258387, @glebius wrote:

struct _bar {
        int x;
};

struct foo {
        struct _bar;
        int y;
};

struct foo.x = 17;

That's pretty evil! I don't think we should encourage that around the kernel. C11 anonymous unions & structs don't leave any space for ambiguity, they do quite the opposite. This extension looks pretty scary, as I may have x in bar and in baz, and then make both baz and bar member of foo.

that just fails with error: duplicate member 'x'

But it's funny given jhb in an email thread pointed out that it was you moving this globally enabled in the kernel for gcc in cc4a90c445aa04be36c3ef745cbe67fa339b94b5 . I don't think that commit did what you thought it would back then.

I can't understand why do we need the global (pre-vnet) list. Can the queue just hang off the in6_ifaddr?

Bruce, very glad to see you back!!!

• Use rcvmtxopts as Mark suggests.

In D54948#1257019, @afedorov wrote:

Maybe someone remembers this project: https://lists.freebsd.org/pipermail/freebsd-current/2014-September/052226.html

In D54948#1256749, @zlei wrote:

Might be off-topic. I have ever had an idea, that introducing SOFT checksum offload to all soft interfaces. The upper stack will see this and hand over the calculating of the checksums to the interfaces. The soft interfaces may calculate the checksums when absolutely necessary, or let the edge physical interfaces do the stuff when the packets are leaving the host. Then we can benefits the hardware checksum, or we have better icache locality ( batch processing the mbufs ) when doing soft checksum.

What do you think ?

Question on naming. I would read "resultproc" as "result process". What does "resultprot" stands for?