Looks good to me. This is a well reasoned list to remove in order to make sure we can support the remaining platforms.

Remove the drain limit completely and instead try to fill the TX queue on each drain.

In D18532#395386, @olivier wrote:

tx_abdicate still brings lot's major gain against D18532.
Theory invalided ?

Hmm, there was https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229432 and corresponding commit https://svnweb.freebsd.org/base?view=revision&revision=336195 fixing the problem.

The general idea seems sound to me. Ideally NIC drivers would also handle it gracefully, but this is nice in that it is close to the source (well, one common source). In fact, iflib handles this gracefully already:

In D18535#395370, @sobomax wrote:

In D18535#395273, @eugen_grosbein.net wrote:

Yes, it requires corruption of private node memory. As owner of multiple routers mass servicing thousands of customers using multiple NETGRAPH nodes I can assure you that panic is not appropriatie action. Appropriate action is some form of block for traffic flow trough the node in question (with logging) leaving other nodes working.

Well, that's where I respectively disagree. As an owner of hundreds of FreeBSD systems servicing many millions of customers I think that rebooting the system immediately after any slight kernel heap/stack memory corruption is detected is not just appropriate but the only sane action available. Shutting down particular netgraph node and hope for the best would just leave the service down indefinitely with no hope for any sorts of automatic recovery.

fix build

Stephen Hurd, this is what I believe to be the correct fix for this issue. I'm not entirely certain how to reproduce the original setup that triggered the bug, so some help with that would be appreciated.

I think this is obsoleted by my review at https://reviews.freebsd.org/D17947 ?

Might as well apply a similar fix to aarch64/reloc.c, which does something sort of similar (symval). Other archs look different enough not to produce the same warning. (aarch64's use may be simpler enough that the warning is not produced, either, but I have not tried it.)

Silence warnings in code instead of disabling the warning.

The reason for this change is that currently, a send/recv appears to take many hours to time out. This is suboptimal in the bootloader because it means for example that NFS will take hours to fail before allowing subsequent access methods such as gzip to be tried.

Remove the unintended change of updating MAXWAIT

Here is my DoS benches results on my smallest 2 hardwares.
First serie comparing the benefit of D18532, so with tx_abdicate disabled (default behaviour)

Remove more of the 33292 magic numbers

Add LICENSEFILE
Change BUILD_DEPENDS to TEST_DEPENDS
Add missing TEST_DEPENDS and RUN_DEPENDS
Add do-test target

Sorry, I missed the last upload of this.

In D18535#395273, @eugen_grosbein.net wrote:

Looks good with one exception: additional plain panic(). Can it be replaced with KASSERT?

IDK, there is no way this option to be set to anything but DLT_RAW or DLT_EN10MB in the course of normal operation of the node. So it would require some form of memory corruption to actually happen. IDK, panic(9) seems an appropriate action in that case. There are other panic(9) call in the code in similar situations.

Yes, it requires corruption of private node memory. As owner of multiple routers mass servicing thousands of customers using multiple NETGRAPH nodes I can assure you that panic is not appropriatie action. Appropriate action is some form of block for traffic flow trough the node in question (with logging) leaving other nodes working.

tweak UPDATING and pkg-message in line with diff

Ping?

These drops of performance with tx_abdicate which is almost 2 times looks like RSS failure?..

With this patch and *with* tx_abdicate results are mixed.

Yea, 1 week.

• Flatten rename as it breaks getting the patch via download link (again)

• Update to 18.3.1

• Update to 18.2.7

Thanks. Do you plan to MFC this?

I could say, that with this patch and *without* tx_abdicate results are:

1. Without IPsec is the same both in bandwidth (kb/s) and throughput (pps) is not worse than without it. It is hard to say, that it is better as it is near ability of my test rig to generate traffic anyway.
2. With IPsec it is slightly better both for bandwidth and throughput in both directions.