4ad8cb68 tuexen Oct. 19, 2019, 8:48 p.m.
Thanks to cem@ for discussing the issue which resulted in this patch.

Reviewed by:		cem@
Sponsored by:		Netflix, Inc.
Differential Revision:	https://reviews.freebsd.org/D22089
cgit ViewVC
91ad311b jlh Oct. 19, 2019, 7:52 p.m.
Reviewed by:	jilles
MFC after:	1 week
Relnotes:	yes
Differential Revision:	https://reviews.freebsd.org/D21880
cgit ViewVC
ce0372d7 jlh Oct. 19, 2019, 7:38 p.m.
1a352c3c cem Oct. 19, 2019, 4:37 p.m.
This allows specifying a boot-time preference in loader.conf.
cgit ViewVC
4ffdb9f2 jhibbits Oct. 19, 2019, 4:09 p.m.
a009b7dc jkim Oct. 19, 2019, 2:56 p.m.
6b74887f tsoome Oct. 19, 2019, 8:08 a.m.
When zfs probe did fail and no spa was created, but zfs_fmtdev() is called,
we will crash while dereferencing spa (NULL pointer dereference).

MFC after:	1 week
cgit ViewVC
01a69565 avg Oct. 19, 2019, 7:16 a.m.
This should change nothing for kernel configurations at the standard
locations in the source tree.  However, if KERNCONFDIR is used to
specify a custom location for a kernel configuration file (e.g., out of
tree), then both the custom location and the standard location, in this
order, will be used as include paths for config(8).  This will allow the
kernel configuration to include files from both locations.

Reviewed by:	bdrewery
MFC after:	16 days
Differential Revision: https://reviews.freebsd.org/D22057
cgit ViewVC
3aa8a8ed avg Oct. 19, 2019, 7:13 a.m.
The rationale is pretty much the same as in r353747.
There is no subsequent dependent store.
The store is to the regular (TSO) memory anyway.

MFC after:	23 days
cgit ViewVC
869dbab7 avg Oct. 19, 2019, 7:10 a.m.
After removing wmb(), vm_set_rendezvous_func() became super trivial, so
there was no point in keeping it.

The wmb (sfence on amd64, lock nop on i386) was not needed.  This can be
explained from several points of view.

First, wmb() is used for store-store ordering (although, the primitive
is undocumented).  There was no obvious subsequent store that needed the
barrier.

Second, x86 has a memory model with strong ordering including total
store order.  An explicit store barrier may be needed only when working
with special memory (device, special caching mode) or using special
instructions (non-temporal stores).  That was not the case for this
code.

Third, I believe that there is a misconception that sfence "flushes" the
store buffer in a sense that it speeds up the propagation of stores from
the store buffer to the global visibility.  I think that such
propagation always happens as fast as possible.  sfence only makes
subsequent stores wait for that propagation to complete.  So, sfence is
only useful for ordering of stores and only in the situations described
above.

Reviewed by:	jhb
MFC after:	23 days
Differential Revision: https://reviews.freebsd.org/D21978
cgit ViewVC
f1d4707c jhibbits Oct. 19, 2019, 2:47 a.m.
a877eb61 jhibbits Oct. 19, 2019, 1:07 a.m.
PCI controllers need to enforce exclusive config register access on their
own bus, not between all buses.
cgit ViewVC
7dd22bae jkim Oct. 18, 2019, 10:08 p.m.
0634308d cem Oct. 18, 2019, 10:03 p.m.
Introduced in r353685 (sys/conf/files), r353694 (debugnet.c db_printf).

Submitted by:	kevans
Reported by:	cy
X-MFC-With:	r353685, r353694
cgit ViewVC
f8bc74e2 vmaffione Oct. 18, 2019, 9:53 p.m.
This patch is part of an effort to make bhyve networking (in particular TCP)
faster. The key strategy to enhance TCP throughput is to let the whole packet
datapath work with TSO/LRO packets (up to 64KB each), so that the per-packet
overhead is amortized over a large number of bytes.
This capability is supported in the guest by means of the vtnet(4) driver,
which is able to handle TSO/LRO packets leveraging the virtio-net header
(see struct virtio_net_hdr and struct virtio_net_hdr_mrg_rxbuf).
A bhyve VM exchanges packets with the host through a network backend,
which can be vale(4) or if_tap(4).
While vale(4) supports TSO/LRO packets, if_tap(4) does not.
This patch extends if_tap(4) with the ability to understand the virtio-net
header, so that a tapX interface can process TSO/LRO packets.
A couple of ioctl commands have been added to configure and probe the
virtio-net header. Once the virtio-net header is set, the tapX interface
acquires all the IFCAP capabilities necessary for TSO/LRO.

Reviewed by:	kevans
Differential Revision:	https://reviews.freebsd.org/D21263
cgit ViewVC