Update the comment about alloc/free ordering.

In D16457#396393, @rene wrote:

I suggest to wait for 2019Q1, then:

• update proudriere(-devel) with @mat 's patch
• update user/developer documentation
• rebase the patch
• commit the patch
• send out some emails to announce subpackages

Remove unintended README change

So what happen when somebody run 'mount -a' second time, with non-idempotent mount option + update ?

• Update to Beta 5

This change does not seem wrong, though the only way I can see it being usable is to have the read-only mount's in /etc/fstab, then a special fstab that has the desired update mount lines in it. Because if the update mount's are in /etc/fstab, then for 'mount -a' the read-only mount will happen immediately followed by the read-write mount. Though I suppose that the update mount line could appear first (and fail) followed by the read-only mount which would presumably succeed. Then on the second 'mount -a' the update would succeed and the read-only would be skipped because it was already mounted. But this seems like a really obscure way of doing things. Plus you would have to change mount so that would not exit when the initial "ro,update" failed.

Also add an exception to the mbuf count limit rule. This is the one being triggered by the git clone https://github.com/freebsd/freebsd.git command. With this fix, it runs to completion without a problem.

The following pkt-gen command:

In D18545#395726, @shurd wrote:

In D18545#395423, @jacob.e.keller_intel.com wrote:

I'm not entirely certain how to reproduce the original setup that triggered the bug, so some help with that would be appreciated.

The easiest way to trigger the issue is to use net/pkt-gen to send a fixed number of packets. With the bug, pkt-gen would never complete because it wasn't notified that all packets were sent.

Other platform (supermicro 5018A-FTN4, Atom C2758 8-cores at 2.4Ghz with intel 82599ES 10-Gigabit):

x r342020 with D18532(old: diff51924) and tx_abdicate disabled (default): inet4 pps
+ r342020 with D18532(new: diff51986) and tx_abdicate disabled (default): inet4 pps
+--------------------------------------------------------------------------+
| x             xx                      +    +          *               + +|
||______________M____A____________________|                                |
|                                         |_____________MA_______________| |
+--------------------------------------------------------------------------+
    N           Min           Max        Median           Avg        Stddev
x   5       3179260       3260787       3200772     3208284.5     30758.531
+   5       3235848       3287655       3260728     3262531.6     23384.011
Difference at 95.0% confidence
        54247.1 +/- 39846.4
        1.69084% +/- 1.25533%
        (Student's t, pooled s = 27321.2)

In D18520#396447, @sef wrote:

Ok. I can get them split up such that they compile, at least.

They should be fully independent algorithms / steps, even if they don't have a consumer until the last step. If they're integrated in a way that they can't be separated and at least compile, I think that's a problem.

I just tested this patch on a machine using the scenario jhb@ mentioned:
Running git clone https://github.com/freebsd/freebsd.git. It still fails.

In D18520#396394, @sef wrote:

So I'm unsure why those would really be broken up -- they're integrated, and the code can't be used (as I recall) unless all three of those items are present.

LGTM; would appreciate also hearing @rrs's opinion.