r323849 n_hibma Sept. 21, 2017, 9:27 a.m.
r323848 n_hibma Sept. 21, 2017, 9:22 a.m.
r323847 tuexen Sept. 21, 2017, 9:18 a.m.
MFC after:	1 week
r323843 cem Sept. 21, 2017, 5:46 a.m.
Without nist-kat installed, cryptotest.py is a no-op.  Showing 'success' in
that case is unhelpful.

Sponsored by:	Dell EMC Isilon
r323841 rmacklem Sept. 21, 2017, 12:41 a.m.
These definitions will be used by a future commit.
r323840 jkim Sept. 21, 2017, 12:03 a.m.
MFC after:	3 days
r323839 ae Sept. 20, 2017, 10:35 p.m.
to determine that an address is our local.

PR:		220078
MFC after:	1 week
r323836 ae Sept. 20, 2017, 10 p.m.
Acquiring of IPFW_WLOCK is requried for cases when we are going to
change some data that can be accessed during processing of packets flow.
When we create new named object, there are not yet any rules, that
references it, thus holding IPFW_UH_WLOCK is enough to safely update
needed structures. When we destroy an object, we do this only when its
reference counter becomes zero. And it is safe to not acquire IPFW_WLOCK,
because noone references it. The another case is when we failed to finish
some action and thus we are doing rollback and destroying an object, in
this case it is still not referenced by rules and no need to acquire

This also fixes panic with INVARIANTS due to recursive IPFW_WLOCK acquiring.

MFC after:	1 week
Sponsored by:	Yandex LLC
r323834 imp Sept. 20, 2017, 9:42 p.m.
1/4 of the number of queues times queue entries is too limiting. It
works up to about 4k IOPS / 3.0GB/s for hardware that can do
4.4k/3.2GB/s with nvd. 3/4 works better, though it highlights issues
in the fairness of nda's choice of TRIM vs READ. That will be fixed
r323833 tuexen Sept. 20, 2017, 9:29 p.m.
MFC after:	1 week
r323832 imp Sept. 20, 2017, 9:26 p.m.
Previously ios->current was set to 0 until the first
cam_iosched_cl_maybe_steer() call.

PR: 221954
Obtained from: ElectroBSD
Submitted by: Fabian Keil
Differential Revision: https://reviews.freebsd.org/D12349
r323831 imp Sept. 20, 2017, 9:25 p.m.
Previously callout_reset() was called with a "ticks" value that was
off by one.  As a result cam_iosched_ticker() was called a bit too
frequently: On systems with hz=1000 a quanta value of 200 resulted in
~250 calls and a value of 100 in ~111 calls.

For the "queue_depth" and "bandwidth" limiters the difference doesn't
matter but the "iops" limiter depends on the scheduling to enforce the
correct maximum.

PR: 221956
Obtained from: ElectroBSD
Submitted by: Fabian Keil
Differential Revision: https://reviews.freebsd.org/D12350
r323829 imp Sept. 20, 2017, 9:19 p.m.
Invalid values can result in devision-by-zero panics or other
undefined behaviour so lets not allow them.

PR: 221957
Obtained from: ElectroBSD
Submitted by: Fabian Keil
Differential Revision: https://reviews.freebsd.org/D12351
r323828 imp Sept. 20, 2017, 9:13 p.m.
Use the write queue for BIO_ZONE commands so they can't get executed
ahead of writes that were sent after them. More generally, since they
introduce strong ordering into the list, they need to go to the write
queue (which is the only queue that BIO_ORDERED is honored for at the
moment). In fact, fix mismatch between queueing and dequeueing code by
changing this to queue all non-reads (and non-trims) to the write

As a side effect this prevents the kernel message:
kernel: Found bio_cmd = 0x9
which cam_iosched_next_bio() emits when finding commands
other than BIO_READ in the read queue.

PR: 221973
Obtained from: ElectroBSD
Submitted by: Fabian Keil
Differential Revision: https://reviews.freebsd.org/D12353
r323825 shurd Sept. 20, 2017, 8:40 p.m.
RXQ setup for netmap was broken because netmap_rxq_init was getting called
before IFDI_INIT - thus we ended up with ring tail pointer being reset to zero.

Reviewed by:	sbruno
Approved by:	sbruno (mentor)
Sponsored by:	Limelight Networks
Differential Revision:	https://reviews.freebsd.org/D12140