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)
MFC after: 2 weeks
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8964
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)
MFC after: 2 weeks
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8962
This will be used by the coming NIC SR-IOV patch.
Reviewed by: sephe
Approved by: sephe (mentor)
MFC after: 2 weeks
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8909
If bufring is used for per-TX ring descs, don't update "available"
counter, which is only used to help debugging.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8674
It was an experimental tunable, and is now deemed to be road blocker
for further changes. Time to retire it.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8654
Just in case that no chimney sending buffer can be used.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8619
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.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8559
Just in case, the # of TX/RX rings is changed upon synthetic parts
re-attach.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8520
And re-enable SIOCADDMULTI/SIOCDELMULTI, after WITNESS warning is fixed.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8489
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.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8560
And put them under HN_IFSTART_SUPPORT, which is by default on until
we whack the if_start related bits from base system.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8392
- Move the SYSINIT to DRIVER/SECOND, i.e. after the vm_guest becomes
determistic.
- Minor style changes.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8370
Mainly because the host side only set TCPCS and IPCS even for
UDP datagrams.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8369
And use large default temporary channel packer buffer; we really
don't want it to be expanded at run time.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8367
This paves way for more chimney sending buffer reorganization.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8343
Link status check is much more lightweight than network change detection.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8311
This will not happen in real world, since TX consumption of the vmbus
TX bufring is limitted. Better safe than sorry.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8309
All RNDIS control messages have used SG list for a while. This makes
the send context suitable for further refactoring.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8308
Currently the network change is simulated by link status changes.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8295
This is the preamble for network device SR-IOV and
NDIS_STATUS_NETWORK_CHANGE handling.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8209
The _correct_ way to identify the supported checksum offloading and
TSO parameters is to query OID_TCP_OFFLOAD_HARDWARE_CAPABILITIES.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8088
This prepares to consolidate hn_stop() and netvsc_detach().
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8055
Suspend:
- Prevent the backend from being touched on TX path.
- Clear the RNDIS RX filter, and wait for RX to drain.
- Make sure that NVS see the chimney sending buffer and RXBUF
disconnection, before unlink these buffers from the channel.
Resume:
- Reconfigure the RNDIS filter.
- Allow TX path to work on the backend.
- Kick start the TX eof task, in case the OACTIVE is set.
This fixes various panics, when the interface has traffic and MTU
is being changed.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8046
So that reinitialization, e.g. MTU change, will not fail when the system
memory is excessively fragmented.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D7961
So that NVS version probing failure does not look too scary.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D7950
- Don't change RNDIS RSS configuration for RSS key sysctl, if the
interface is not capable of RSS yet.
- Don't change RSS indirect table (both cached one and RNDIS RSS
configuration), if the interface is not capable of RSS yet.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D7924
And don't allow capability changes during reinitialization, which
breaks too much static configuration.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D7922
NVS and NDIS version change would break too much assumption and static
configuration.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D7919
While I'm here, add comment along the attach DEVMETHOD.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D7874
- ifnet.if_mtu does not require explicit setting.
- ifnet.if_hdrlen must be set after ether_ifattach().
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D7873
It is available on both stable/10 and stable/11. This eases future MFCs
to stable/10.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D7872
