Hi, sorry for my silence. I was busy with other tasks, and it seems forget GEOM a bit.
I think you need to test your code with BSD scheme, AFAIR, it uses stripeoffset field.

Missed one case when PCB could be unlocked before check - when PCB is
already dying and imo is NULL. Also remove extra IN6_IS_ADDR_MULTICAST(),
we already checked it few lines before.

In D28232#631463, @gnn wrote:

Yup, I understand that we do not currently have that function. I think you ought to add that as part of this fix.

Before epochification we had an integer variable that was used to track locking.

#define        UH_WLOCKED      2
#define        UH_RLOCKED      1
#define        UH_UNLOCKED     0

And currently rwlock doesn't provide public function or macro similar to rw_wowned() for shared lock.

I have some doubts, that this change is safe. But probably we will see the result quickly.

If you tested the change and it works for you, I have no objection.

We already have IP_SENDONES flag for ip_output, that should serve for this purpose. Maybe is it not safe enough to allow this feature for all protocols?

I think the patch in D28187 is better. You need to release reference to SP when error occurs before ipsec4_process_packet().

It seems part of this is already in D28160

It seems I found how to reproduce it on test system:

1. Load systemt without any unneeded modules
2. kldload dtraceall
3. Run

# dtrace -n 'fbt::ip_input:entry { printf("%s", stringof(args[0]->m_pkthdr.rcvif->if_xname)); }'
dtrace: description 'fbt::ip_input:entry ' matched 1 probe
CPU     ID                    FUNCTION:NAME
  2  49220                   ip_input:entry ix0
  2  49220                   ip_input:entry ix0
  6  49220                   ip_input:entry ix0
^C
# kldunload dtraceall
# kldload ipfw
# kldload dtraceall
# dtrace -n 'fbt::ip_input:entry { printf("%s", stringof(args[0]->m_pkthdr.rcvif->if_xname)); }'
dtrace: invalid probe specifier fbt::ip_input:entry { printf("%s", stringof(args[0]->m_pkthdr.rcvif->if_xname)); }: in action list: m_pkthdr is not a member of struct mbuf

Recently I faced with this problem on some machines:

# dtrace -n 'fbt::ip_input:entry { printf("%s", stringof(args[0]->m_pkthdr.rcvif->if_xname)); }'
dtrace: invalid probe specifier fbt::ip_input:entry { printf("%s", stringof(args[0]->m_pkthdr.rcvif->if_xname)); }: in action list: m_pkthdr is not a member of struct mbuf

In D26879#599390, @gnn wrote:

I like the idea of this change but I believe that a new file should be created in netpfil/ipfw to contain the code that's been put into in_kdtrace.[ch] in this review.

Move provider and probe definitions into ipfw2.c

In D26879#599390, @gnn wrote:

I like the idea of this change but I believe that a new file should be created in netpfil/ipfw to contain the code that's been put into in_kdtrace.[ch] in this review.

LGTM. However it would be nice, if you consider my comments :)

It seems the only solution here is taking ifnet reference. I'm not sure about PCB, probably it can not disappear here.

Looks correct to me.

The code refers what you named "processing actions" as "policy levels". Take a look at netipsec/ipsec.h

Yes. But I don't think the patch is heavy. Lets try to look from a different point.
SO_REUSEPORT_LB was introduced in D11003 with several fixes later, it has the same purpose - extend scalability of user space programs, that was used for example by DNS server.
The kernel should provide useful features for applications. Your app can use simple sockets API to send data, but also it can use more productive sendfile(2) syscall, etc.
OpenVPN is free opensource application that is widely used and supports different OSes. When all employee in your company are going work remotely, you can buy some hardware and thousands of licenses or can just use relatively small patch. This patch helps to extend scalability of OpenVPN for us, but it can be used for another apps that we don't use. I'm not forcing to commit it into base system, just share our experience and ask for comments.

I think IF_ADDR_WLOCK() is not required for this ioctl. It is enough to use NET_EPOCH_ENTER().

It seems you missed hash calculation for udp[6]_output(), when socket isn't connected and destination address is specified by caller.

Committed as rS365628.

I think this patch is too complicated. Can you properly test this patch instead? https://people.freebsd.org/~ae/ipfw_frag.diff

LGTM.

I sent a more generic patch in the reply to your email a week ago, can you check your spam folder and test it?

LGTM.

I think it should be possible solve the problem without introducing extra configuration parameter. I'll take a look.

LGTM.

LGTM.

In D24989#552576, @avg wrote:

I have a vague memory, maybe wrong, that commonly used fixed RSS keys were selected because they had some property (-ies).
So, maybe just being random is not good enough?
I think that hypothetical rss_isbadkey was mentioned for a reason?

LGTM.

How many subscribers do you expect? I think you will replace some existing. Maybe it would be better to have separate list for each subscription type?

You can just use another option name to specify excludes.