Hyper-V: hn: use VF's capabilities when it is attached

Current code in hn/netvsc tries to merge (logical AND) VF and
its own capability bits when a VF is attached. This results in
losing some key V

Hyper-V: hn: use VF's capabilities when it is attached

Current code in hn/netvsc tries to merge (logical AND) VF and
its own capability bits when a VF is attached. This results in
losing some key VF features, especially in tx path. For example,
the VF's txcsum, rxcsum or tso bits could be lost if any of
these are not in hn/netvsc's own capablility field.

Actually when VF is attached, hn just needs to use VF's caps
as all the tx packets would be forwarded to the VF interface.
Fix this problem by doing so.

Reported by: whu
Tested by: whu
MFC after: 3 days
Sponsored by: Microsoft

show more ...

sys: Remove $FreeBSD$: two-line .h pattern

Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/

Switch to contigmalloc in the Hyper-V code

In the Hyper-V drivers we need to allocate buffers shared between the
host and guest. This memory has been allocated with bus_dma, however
it doesn't use t

Switch to contigmalloc in the Hyper-V code

In the Hyper-V drivers we need to allocate buffers shared between the
host and guest. This memory has been allocated with bus_dma, however
it doesn't use this correctly, e.g. it is missing calls to
bus_dmamap_sync. Along with this on arm64 we need this memory to be
mapped with the correct memory type that bus_dma may not use.

Switch to contigmalloc to allocate this memory as this will correctly
allocate cacheable memory.

Reviewed by: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D40227

show more ...

Mechanically convert if_hn(4) to IfAPI

Reviewed by: zlei
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D37855

Hyper-V: hn: add switch to turn on and off RSC

Currently RSC offloading is enabled by default.
With this new change rsc will be disabled by default.
By using sysctl we can enable and disable it.

Re

Hyper-V: hn: add switch to turn on and off RSC

Currently RSC offloading is enabled by default.
With this new change rsc will be disabled by default.
By using sysctl we can enable and disable it.

Reviewed by: whu
Signed-off-by: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Fixes: a491581f3f8df Enable vSwitch RSC support in hn netvsc driver
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D34507

show more ...

Hyper-V: hn: Enable vSwitch RSC support in hn netvsc driver

Receive Segment Coalescing (RSC) in the vSwitch is a feature available in
Windows Server 2019 hosts and later. It reduces the per packet p

Hyper-V: hn: Enable vSwitch RSC support in hn netvsc driver

Receive Segment Coalescing (RSC) in the vSwitch is a feature available in
Windows Server 2019 hosts and later. It reduces the per packet processing
overhead by coalescing multiple TCP segments when possible. This happens
mostly when TCP traffics are among different guests on same host.
This patch adds netvsc driver support for this feature.

The patch also updates NVS version to 6.1 as needed for RSC
enablement.

MFC after: 2 weeks
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D29075

show more ...

Merge ^/head r323559 through r325504.

MFhead@r324497

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_PARAM

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.

MFC after: 3 days
Sponsored by: Microsoft

show more ...

MFhead@r320180

hyperv/hn: Incease max supported MTU

MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D12365

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

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.

MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D12333

show more ...

Merge ^/head r322398 through r322746.

MFhead@r322515

hyperv: Update copyright for the files changed in 2017

MFC after: 3 days
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11982

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

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.

MFC after: 3 days
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11978

show more ...

MFhead@r322451

Merge ^/head r321383 through r322397.

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 coorespo

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).

MFC after: 3 days
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11803

show more ...

MFhead@r321970

MFhead@r321851

hyperv/hn: Renaming and minor cleanup

This prepares for the upcoming transparent VF support.

MFC after: 3 days
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11708

MFhead@r320180

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

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

MFC after: 3 days
Sponsored by: Microsoft
Differential Revision: https://reviews.freeb

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

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

MFC after: 3 days
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11618

show more ...

MFhead@r313243