MFC r356201:
Fix spelling.

PR: 242891
Sponsored by: Mellanox Technologies

MFC: 339585

r339585:
Do not drop UDP traffic when TXCSUM_IPV6 flag is on

PR: 231797
Submitted by: whu
Reviewed by: dexuan
Obtained from: Kevin Morse
Sponsored by: Microsoft

MFC: 336426

r336426
hyperv/hn: Fix panic in hypervisor code upon device detach event

Submitted by: hselasky
Reviewed by: dexuan
Differential Revision: https://reviews.freebsd.org/D16139

MFC 324517

hyperv/hn: Enable transparent VF by default.

Sponsored by: Microsoft

MFC 324489,324516

324489
hyperv/hn: Workaround erroneous hash type observed on WS2016.

Background:
- UDP 4-tuple hash type is unconditionally enabled in Hyper-V on WS2016,
which is _not_ affected by NDIS_OBJTYPE_RSS_PARAMS.
- Non-fragment UDP/IPv4 datagrams' hash type is delivered to VM as
TCP_IPV4.

Currently this erroneous behavior only applies to WS2016/Windows10.

Force l3/l4 protocol check, if the RXed packet's hash type is TCP_IPV4,
and the Hyper-V is running on WS2016/Windows10. If the RXed packet is
UDP datagram, adjust mbuf hash type to UDP_IPV4.

Sponsored by: Microsoft

324516
hyperv/hn: Workaround erroneous hash type observed on WS2016 for VF.

The background was described in r324489.

Sponsored by: Microsoft

MFC 324049,324077

324049
hyperv/hn: Fix UDP checksum offload issue in Azure.

UDP checksum offload does not work in Azure if following conditions are
met:
- sizeof(IP hdr + UDP hdr + payload) > 1420.
- IP_DF is not set in IP hdr

Use software checksum for UDP datagrams falling into this category.

Add two tunables to disable UDP/IPv4 and UDP/IPv6 checksum offload, in
case something unexpected happened.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D12429

324077
hyperv/hn: Unbreak i386 building.

Reported by: cy
Sponsored by: Microsoft

MFC 324048

hyperv/hn: Set tcp header offset for CSUM/LSO offloading.

No observable effect; better safe than sorry.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D12417

MFC 323728,323729

323728
hyperv/hn: Fix MTU setting

- Add size of an ethernet header to the value configured to NVS. This
does not seem to have any effects if MTU is 1500, but fix hypervisor
side's setting if MTU > 1500.
- Override the MTU setting according to the view from the hypervisor
side.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D12352

323729
hyperv/hn: Incease max supported MTU

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D12365

MFC 323727,324316

323727
hyperv/hn: Apply VF's RSS setting

Since in Azure SYN and SYN|ACK go through the synthetic parts while the
rest of the same TCP flow goes through the VF, apply VF's RSS settings
to synthetic parts to have a consistent hash value/type for the same TCP
flow.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D12333

324316
hyperv/hn: Fix options RSS building

Reported by: np
Sponsored by: Microsoft

MFC 323175

hyperv/hn: Implement SIOCGIFRSS{KEY,HASH}.

The conditional compiling in the review request is removed, since
these IOCTLs will be available in stable/10 and stable/11.

Reviewed by: gallatin
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D12175

MFC 322488

hyperv: Update copyright for the files changed in 2017

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11982

MFC 322299,322483,322485-322487

322299
hyperv/hn: Implement transparent mode network VF.

How network VF works with hn(4) on Hyper-V in transparent mode:

- Each network VF has a cooresponding hn(4).
- The network VF and the it's cooresponding hn(4) have the same hardware
address.
- Once the network VF is attached, the cooresponding hn(4) waits several
seconds to make sure that the network VF attach routing completes, then:
o Set the intersection of the network VF's if_capabilities and the
cooresponding hn(4)'s if_capabilities to the cooresponding hn(4)'s
if_capabilities. And adjust the cooresponding hn(4) if_capable and
if_hwassist accordingly. (*)
o Make sure that the cooresponding hn(4)'s TSO parameters meet the
constraints posed by both the network VF and the cooresponding hn(4).
(*)
o The network VF's if_input is overridden. The overriding if_input
changes the input packet's rcvif to the cooreponding hn(4). The
network layers are tricked into thinking that all packets are
neceived by the cooresponding hn(4).
o If the cooresponding hn(4) was brought up, bring up the network VF.
The transmission dispatched to the cooresponding hn(4) are
redispatched to the network VF.
o Bringing down the cooresponding hn(4) also brings down the network
VF.
o All IOCTLs issued to the cooresponding hn(4) are pass-through'ed to
the network VF; the cooresponding hn(4) changes its internal state
if necessary.
o The media status of the cooresponding hn(4) solely relies on the
network VF.
o If there are multicast filters on the cooresponding hn(4), allmulti
will be enabled on the network VF. (**)
- Once the network VF is detached. Undo all damages did to the
cooresponding hn(4) in the above item.

NOTE:
No operation should be issued directly to the network VF, if the
network VF transparent mode is enabled. The network VF transparent mode
can be enabled by setting tunable hw.hn.vf_transparent to 1. The network
VF transparent mode is _not_ enabled by default, as of this commit.

The benefit of the network VF transparent mode is that the network VF
attachment and detachment are transparent to all network layers; e.g. live
migration detaches and reattaches the network VF.

The major drawbacks of the network VF transparent mode:
- The netmap(4) support is lost, even if the VF supports it.
- ALTQ does not work, since if_start method cannot be properly supported.

(*)
These decisions were made so that things will not be messed up too much
during the transition period.

(**)
This does _not_ need to go through the fancy multicast filter management
stuffs like what vlan(4) has, at least currently:
- As of this write, multicast does not work in Azure.
- As of this write, multicast packets go through the cooresponding hn(4).

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11803

322483
hyperv/hn: Update VF's ibytes properly under transparent VF mode.

While, I'm here add comment about why updating VF's imcast stat is
not necessary.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11948

322485
hyperv/hn: Fix/enhance receiving path when VF is activated.

- Update hn(4)'s stats properly for non-transparent mode VF.
- Allow BPF tapping to hn(4) for non-transparent mode VF.
- Don't setup mbuf hash, if 'options RSS' is set.
In Azure, when VF is activated, TCP SYN and SYN|ACK go through hn(4)
while the rest of segments and ACKs belonging to the same TCP 4-tuple
go through the VF. So don't setup mbuf hash, if a VF is activated
and 'options RSS' is not enabled. hn(4) and the VF may use neither
the same RSS hash key nor the same RSS hash function, so the hash
value for packets belonging to the same flow could be different!
- Disable LRO.
hn(4) will only receive broadcast packets, multicast packets, TCP
SYN and SYN|ACK (in Azure), LRO is useless for these packet types.
For non-transparent, we definitely _cannot_ enable LRO at all, since
the LRO flush will use hn(4) as the receiving interface; i.e.
hn_ifp->if_input(hn_ifp, m).

While I'm here, remove unapplied comment and minor style change.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11978

322486
hyperv/hn: Minor cleanup

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11979

322487
hyperv/hn: Re-set datapath after synthetic parts reattached.

Do this even for non-transparent mode VF. Better safe than sorry.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11981

Approved by: re (delphij)

MFC 321836,321837

321836
hyperv/hn: Renaming and minor cleanup

This prepares for the upcoming transparent VF support.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11708

321837
hyperv/hn: Add comment about ether_ifattach event subscription.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11710

MFC 321409

hyperv/hn: Ignore LINK_SPEED_CHANGE status.

This status will be reported if the backend NIC is wireless; it's not
useful. Due to the high frequency of the reporting, this could be
pretty annoying; ignore it.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11651

MFC 321407

hyperv/hn: Export VF list and VF-HN mapping

The VF-HN map will be used later on to implement "transparent VF".

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11618

MFC 317353

hyperv/hn: Use channel0, i.e. TX ring0, for TCP SYN/SYN|ACK.

Hyper-V hot channel effect:
Operation latency on hot channel is only _half_ of the operation
latency on cold channels.

This commit takes the advantage of the above Hyper-V host channel
effect, and can reduce more than 75% latency and more than 50%
latency stdev, i.e. lower and more stable/predictable latency,
for various types of web server workloads.

Sponsored by: Microsoft

MFC 316520

hyperv/hn: Fixat RNDIS rxfilter after the successful RNDIS init.

Under certain conditions on certain versions of Hyper-V, the RNDIS
rxfilter is _not_ zero on the hypervisor side after the successful
RNDIS initialization, which breaks the assumption of any following
code (well, it breaks the RNDIS API contract actually). Clear the
RNDIS rxfilter explicitly, drain packets sneaking through, and drain
the interrupt taskqueues scheduled due to the stealth packets.

Reported by: dexuan@
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D10230

MFC 314382,314483-314485

314382
hyperv/hn: Simplify RNDIS packet data offset calculation.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D9699

314483
hyperv/hn: Simplify RNDIS packet total length calculation.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D9712

314484
hyperv/hn: Make sure that RNDIS packet message is at least 4B aligned.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D9713

314485
hyperv/hn: Misaligned chimney sending buffers should not be used

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D9714

MFC r312689, r312690

Approved by: sephe (mentor)

r312689
hyperv/hn: add a sysctl name for the VF interface

This makes it easier for the userland script to find the releated
VF interface.

Reviewed by: sephe
Approved by: sephe (mentor)
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D9101

r312690
hyperv/hn: add devctl_notify for VF_UP/DOWN events

Reviewed by: sephe
Approved by: sephe (mentor)
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D9102

MFC: r312688

Approved by: sephe (mentor)

r312688
hyperv/hn: add the support for VF drivers (SR-IOV)

Hyper-V's NIC SR-IOV implementation needs a Hyper-V synthetic NIC and
a VF NIC to work together (both NICs have the same MAC address), mainly to
support seamless live migration.

When the VF device becomes UP (or DOWN), the synthetic NIC driver needs
to switch the data path from the synthetic NIC to the VF (or the opposite).

Note: multicast/broadcast packets are still received through the synthetic
NIC and we need to inject the packets through the VF interface (if the VF is
UP), even if the synthetic NIC is DOWN (so we need to force the rxfilter
to be NDIS_PACKET_TYPE_PROMISCUOUS, when the VF is UP).

Reviewed by: sephe
Approved by: sephe (mentor)
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8964

MFC: r312685, r312686

Approved by: sephe (mentor)

r312685
hyperv/hn: remember the channel pointer in struct hn_rx_ring

This will be used by the coming NIC SR-IOV patch.

Reviewed by: sephe
Approved by: sephe (mentor)
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8909

r312686
hyperv/hn: remove the MTU and IFF_DRV_RUNNING checking in hn_rxpkt()

It's unnecessary because the upper nework stack does the same checking.

In the case of Hyper-V SR-IOV, we need to remove the checking because
1) multicast/broadcast packets are still received through the synthetic
NIC and we need to inject the packets through the VF interface;
2) we must inject the packets even if the synthetic NIC is down, or has
a different MTU from the VF device.

Reviewed by: sephe
Approved by: sephe (mentor)
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8962

MFC 310652,310657,310658

310652
hyperv/hn: Consolidate hn_{suspend,resume}

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8907

310657
hyperv/hn: Function renaming; no functional changes.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8908

310658
hyperv/hn: Factor out function to set rxfilter.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8928

MFC 309874,309875

309874
hyperv/vmbus: Add channel polling support.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8738

309875
hyperv/hn: Add polling support

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8739

MFC 309346,309348

309346
hyperv/hn: Add HN_DEBUG kernel option.

If bufring is used for per-TX ring descs, don't update "available"
counter, which is only used to help debugging.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8674

309348
hyperv/hn: Don't hold txdesc, if no BPFs are attached.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8675

MFC 309310,309311,309316,309318

309310
hyperv/hn: Nuke the unused TX taskqueue CPU binding tunable.

It was an experimental tunable, and is now deemed to be road blocker
for further changes. Time to retire it.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8654

309311
hyperv/hn: Allow multiple TX taskqueues.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8655

309316
hyperv/vmbus: Add DEVMETHOD to map cpu to event taskq.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8658

309318
hyperv/hn: Allow TX to share event taskqueues.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8659

MFC 309226-309231,309235

309226
hyperv/hn: Utilize vmbus_chan_xact_wait

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8612

309227
hyperv/hn: Fix detach error handling.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8613

309228
hyperv/hn: Fix multi-packet RNDIS message aggregation size setting.

Just in case that no chimney sending buffer can be used.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8619

309229
hyperv/hn: Fix attach error handling

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8620

309230
hyperv/hn: Enable multi-packet RNDIS message support by default.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8621

309231
hyperv/hn: Fix vmbus_chan_subidx usage.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8629

309235
hyperv/hn: Simplify RSS indirect table fixup API

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8630

MFC 309085

hyperv/hn: Fix primary channel revocation

Since hypervisor will not drain the TX bufring, once the channels are
revoked:
- Setup vmbus orphan handler properly.
- Make sure that suspension will not wait the TX bufring draining
forever.
- GC the pending TX descs on detach path, before freeing the busdma
stuffs.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8559

MFC 308908,308909

308908
hyperv/hn: Allow enabling IPv6 TX checksum offloading and IPv6 TSO.

They are still disabled by default.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8490

308909
hyperv/hn: Don't abuse hn_{tx,rx}_ring_inuse.

Just in case, the # of TX/RX rings is changed upon synthetic parts
re-attach.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8520

MFC 308907

hyperv/hn: Fix WITNESS warnings

And re-enable SIOCADDMULTI/SIOCDELMULTI, after WITNESS warning is fixed.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8489

MFC 308905

hyperv/hn: Implement RNDIS multi-packet message support.

Currently, it is only applied to packet sent through chimney sending
buffers. Not enabled by default yet.

This one gives 20%~30% performance boost for non-TSO usage in both
bit/packet rate tests and nginx performance test.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8560

MFC 308166,308167

308166
hyperv/hn: Move TSO packet fixup to an earlier place for if_transmit.

While TSO packet header may be still cache-hot.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8393

308167
hyperv/hn: Directly fill chimney sending buffer for small packets.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8394

MFC 308164

hyperv/hn: Regroup if_start related functions.

And put them under HN_IFSTART_SUPPORT, which is by default on until
we whack the if_start related bits from base system.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8392

MFC 308163

hyperv/hn: Rename cleaned up file.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8390