2016-08-09 23:11:07 -04:00
|
|
|
/*-
|
2017-08-14 02:00:50 -04:00
|
|
|
* Copyright (c) 2016-2017 Microsoft Corp.
|
2016-08-09 23:11:07 -04:00
|
|
|
* All rights reserved.
|
|
|
|
|
*
|
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
|
* are met:
|
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
|
* notice unmodified, this list of conditions, and the following
|
|
|
|
|
* disclaimer.
|
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
|
*
|
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
|
|
|
|
|
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
|
|
|
|
|
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
|
|
|
|
|
* IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
|
|
|
|
|
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
|
|
|
|
|
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
|
|
|
|
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
|
|
|
|
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|
|
|
|
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
|
|
|
|
|
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
|
*
|
|
|
|
|
* $FreeBSD$
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef _IF_HNVAR_H_
|
|
|
|
|
#define _IF_HNVAR_H_
|
|
|
|
|
|
2016-10-27 01:13:00 -04:00
|
|
|
#define HN_USE_TXDESC_BUFRING
|
2016-08-16 03:26:53 -04:00
|
|
|
|
2016-10-27 01:13:00 -04:00
|
|
|
#define HN_CHIM_SIZE (15 * 1024 * 1024)
|
2016-08-09 23:11:07 -04:00
|
|
|
|
2016-10-27 01:13:00 -04:00
|
|
|
#define HN_RXBUF_SIZE (16 * 1024 * 1024)
|
|
|
|
|
#define HN_RXBUF_SIZE_COMPAT (15 * 1024 * 1024)
|
|
|
|
|
|
2017-09-19 02:46:00 -04:00
|
|
|
#define HN_MTU_MAX (65535 - ETHER_ADDR_LEN)
|
2016-10-27 01:13:00 -04:00
|
|
|
|
|
|
|
|
#define HN_TXBR_SIZE (128 * PAGE_SIZE)
|
|
|
|
|
#define HN_RXBR_SIZE (128 * PAGE_SIZE)
|
|
|
|
|
|
|
|
|
|
#define HN_XACT_REQ_PGCNT 2
|
|
|
|
|
#define HN_XACT_RESP_PGCNT 2
|
|
|
|
|
#define HN_XACT_REQ_SIZE (HN_XACT_REQ_PGCNT * PAGE_SIZE)
|
|
|
|
|
#define HN_XACT_RESP_SIZE (HN_XACT_RESP_PGCNT * PAGE_SIZE)
|
|
|
|
|
|
|
|
|
|
#define HN_GPACNT_MAX 32
|
2016-08-09 23:11:07 -04:00
|
|
|
|
2016-10-27 01:13:00 -04:00
|
|
|
struct hn_txdesc;
|
|
|
|
|
#ifndef HN_USE_TXDESC_BUFRING
|
|
|
|
|
SLIST_HEAD(hn_txdesc_list, hn_txdesc);
|
|
|
|
|
#else
|
|
|
|
|
struct buf_ring;
|
|
|
|
|
#endif
|
|
|
|
|
struct hn_tx_ring;
|
|
|
|
|
|
|
|
|
|
struct hn_rx_ring {
|
|
|
|
|
struct ifnet *hn_ifp;
|
2017-07-23 23:52:32 -04:00
|
|
|
struct ifnet *hn_rxvf_ifp; /* SR-IOV VF for RX */
|
2016-10-27 01:13:00 -04:00
|
|
|
struct hn_tx_ring *hn_txr;
|
|
|
|
|
void *hn_pktbuf;
|
2016-10-31 00:46:02 -04:00
|
|
|
int hn_pktbuf_len;
|
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
2017-08-14 01:40:52 -04:00
|
|
|
int hn_rx_flags; /* HN_RX_FLAG_ */
|
2017-09-19 02:29:38 -04:00
|
|
|
uint32_t hn_mbuf_hash; /* NDIS_HASH_ */
|
2016-10-27 01:13:00 -04:00
|
|
|
uint8_t *hn_rxbuf; /* shadow sc->hn_rxbuf */
|
|
|
|
|
int hn_rx_idx;
|
|
|
|
|
|
|
|
|
|
/* Trust csum verification on host side */
|
|
|
|
|
int hn_trust_hcsum; /* HN_TRUST_HCSUM_ */
|
|
|
|
|
struct lro_ctrl hn_lro;
|
|
|
|
|
|
|
|
|
|
u_long hn_csum_ip;
|
|
|
|
|
u_long hn_csum_tcp;
|
|
|
|
|
u_long hn_csum_udp;
|
|
|
|
|
u_long hn_csum_trusted;
|
|
|
|
|
u_long hn_lro_tried;
|
|
|
|
|
u_long hn_small_pkts;
|
|
|
|
|
u_long hn_pkts;
|
|
|
|
|
u_long hn_rss_pkts;
|
2016-10-31 00:54:15 -04:00
|
|
|
u_long hn_ack_failed;
|
2016-10-27 01:13:00 -04:00
|
|
|
|
|
|
|
|
/* Rarely used stuffs */
|
|
|
|
|
struct sysctl_oid *hn_rx_sysctl_tree;
|
|
|
|
|
|
|
|
|
|
void *hn_br; /* TX/RX bufring */
|
|
|
|
|
struct hyperv_dma hn_br_dma;
|
2017-01-24 04:09:53 -05:00
|
|
|
|
|
|
|
|
struct vmbus_channel *hn_chan;
|
2016-10-27 01:13:00 -04:00
|
|
|
} __aligned(CACHE_LINE_SIZE);
|
|
|
|
|
|
|
|
|
|
#define HN_TRUST_HCSUM_IP 0x0001
|
|
|
|
|
#define HN_TRUST_HCSUM_TCP 0x0002
|
|
|
|
|
#define HN_TRUST_HCSUM_UDP 0x0004
|
|
|
|
|
|
2016-11-28 00:23:57 -05:00
|
|
|
#define HN_RX_FLAG_ATTACHED 0x0001
|
|
|
|
|
#define HN_RX_FLAG_BR_REF 0x0002
|
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
2017-08-14 01:40:52 -04:00
|
|
|
#define HN_RX_FLAG_XPNT_VF 0x0004
|
2017-10-10 04:32:03 -04:00
|
|
|
#define HN_RX_FLAG_UDP_HASH 0x0008
|
2016-10-27 01:13:00 -04:00
|
|
|
|
|
|
|
|
struct hn_tx_ring {
|
|
|
|
|
#ifndef HN_USE_TXDESC_BUFRING
|
|
|
|
|
struct mtx hn_txlist_spin;
|
|
|
|
|
struct hn_txdesc_list hn_txlist;
|
|
|
|
|
#else
|
|
|
|
|
struct buf_ring *hn_txdesc_br;
|
|
|
|
|
#endif
|
|
|
|
|
int hn_txdesc_cnt;
|
|
|
|
|
int hn_txdesc_avail;
|
|
|
|
|
u_short hn_has_txeof;
|
|
|
|
|
u_short hn_txdone_cnt;
|
|
|
|
|
|
|
|
|
|
int hn_sched_tx;
|
|
|
|
|
void (*hn_txeof)(struct hn_tx_ring *);
|
|
|
|
|
struct taskqueue *hn_tx_taskq;
|
|
|
|
|
struct task hn_tx_task;
|
|
|
|
|
struct task hn_txeof_task;
|
|
|
|
|
|
|
|
|
|
struct buf_ring *hn_mbuf_br;
|
|
|
|
|
int hn_oactive;
|
|
|
|
|
int hn_tx_idx;
|
|
|
|
|
int hn_tx_flags;
|
|
|
|
|
|
|
|
|
|
struct mtx hn_tx_lock;
|
|
|
|
|
struct hn_softc *hn_sc;
|
|
|
|
|
struct vmbus_channel *hn_chan;
|
|
|
|
|
|
|
|
|
|
int hn_direct_tx_size;
|
|
|
|
|
int hn_chim_size;
|
|
|
|
|
bus_dma_tag_t hn_tx_data_dtag;
|
|
|
|
|
uint64_t hn_csum_assist;
|
|
|
|
|
|
2016-11-21 00:00:51 -05:00
|
|
|
/* Applied packet transmission aggregation limits. */
|
|
|
|
|
int hn_agg_szmax;
|
|
|
|
|
short hn_agg_pktmax;
|
|
|
|
|
short hn_agg_align;
|
|
|
|
|
|
|
|
|
|
/* Packet transmission aggregation states. */
|
|
|
|
|
struct hn_txdesc *hn_agg_txd;
|
|
|
|
|
int hn_agg_szleft;
|
|
|
|
|
short hn_agg_pktleft;
|
|
|
|
|
struct rndis_packet_msg *hn_agg_prevpkt;
|
|
|
|
|
|
|
|
|
|
/* Temporary stats for each sends. */
|
|
|
|
|
int hn_stat_size;
|
|
|
|
|
short hn_stat_pkts;
|
|
|
|
|
short hn_stat_mcasts;
|
|
|
|
|
|
2016-10-27 01:13:00 -04:00
|
|
|
int (*hn_sendpkt)(struct hn_tx_ring *, struct hn_txdesc *);
|
|
|
|
|
int hn_suspended;
|
|
|
|
|
int hn_gpa_cnt;
|
|
|
|
|
struct vmbus_gpa hn_gpa[HN_GPACNT_MAX];
|
|
|
|
|
|
|
|
|
|
u_long hn_no_txdescs;
|
|
|
|
|
u_long hn_send_failed;
|
|
|
|
|
u_long hn_txdma_failed;
|
|
|
|
|
u_long hn_tx_collapsed;
|
|
|
|
|
u_long hn_tx_chimney_tried;
|
|
|
|
|
u_long hn_tx_chimney;
|
|
|
|
|
u_long hn_pkts;
|
2016-11-21 00:00:51 -05:00
|
|
|
u_long hn_sends;
|
|
|
|
|
u_long hn_flush_failed;
|
2016-10-27 01:13:00 -04:00
|
|
|
|
|
|
|
|
/* Rarely used stuffs */
|
|
|
|
|
struct hn_txdesc *hn_txdesc;
|
|
|
|
|
bus_dma_tag_t hn_tx_rndis_dtag;
|
|
|
|
|
struct sysctl_oid *hn_tx_sysctl_tree;
|
|
|
|
|
} __aligned(CACHE_LINE_SIZE);
|
|
|
|
|
|
2016-11-28 00:23:57 -05:00
|
|
|
#define HN_TX_FLAG_ATTACHED 0x0001
|
|
|
|
|
#define HN_TX_FLAG_HASHVAL 0x0002 /* support HASHVAL pktinfo */
|
2016-10-27 01:13:00 -04:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Device-specific softc structure
|
|
|
|
|
*/
|
|
|
|
|
struct hn_softc {
|
|
|
|
|
struct ifnet *hn_ifp;
|
|
|
|
|
struct ifmedia hn_media;
|
|
|
|
|
device_t hn_dev;
|
|
|
|
|
int hn_if_flags;
|
|
|
|
|
struct sx hn_lock;
|
|
|
|
|
struct vmbus_channel *hn_prichan;
|
|
|
|
|
|
|
|
|
|
int hn_rx_ring_cnt;
|
|
|
|
|
int hn_rx_ring_inuse;
|
|
|
|
|
struct hn_rx_ring *hn_rx_ring;
|
|
|
|
|
|
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
2017-08-09 01:59:45 -04:00
|
|
|
struct rmlock hn_vf_lock;
|
|
|
|
|
struct ifnet *hn_vf_ifp; /* SR-IOV VF */
|
|
|
|
|
uint32_t hn_xvf_flags; /* transparent VF flags */
|
|
|
|
|
|
2016-10-27 01:13:00 -04:00
|
|
|
int hn_tx_ring_cnt;
|
|
|
|
|
int hn_tx_ring_inuse;
|
|
|
|
|
struct hn_tx_ring *hn_tx_ring;
|
|
|
|
|
|
|
|
|
|
uint8_t *hn_chim;
|
|
|
|
|
u_long *hn_chim_bmap;
|
|
|
|
|
int hn_chim_bmap_cnt;
|
|
|
|
|
int hn_chim_cnt;
|
|
|
|
|
int hn_chim_szmax;
|
|
|
|
|
|
|
|
|
|
int hn_cpu;
|
2016-11-30 00:28:39 -05:00
|
|
|
struct taskqueue **hn_tx_taskqs;
|
2016-10-27 01:13:00 -04:00
|
|
|
struct sysctl_oid *hn_tx_sysctl_tree;
|
|
|
|
|
struct sysctl_oid *hn_rx_sysctl_tree;
|
|
|
|
|
struct vmbus_xact_ctx *hn_xact;
|
|
|
|
|
uint32_t hn_nvs_ver;
|
|
|
|
|
uint32_t hn_rx_filter;
|
|
|
|
|
|
2016-11-21 00:00:51 -05:00
|
|
|
/* Packet transmission aggregation user settings. */
|
|
|
|
|
int hn_agg_size;
|
|
|
|
|
int hn_agg_pkts;
|
|
|
|
|
|
2016-10-27 01:13:00 -04:00
|
|
|
struct taskqueue *hn_mgmt_taskq;
|
|
|
|
|
struct taskqueue *hn_mgmt_taskq0;
|
|
|
|
|
struct task hn_link_task;
|
|
|
|
|
struct task hn_netchg_init;
|
|
|
|
|
struct timeout_task hn_netchg_status;
|
|
|
|
|
uint32_t hn_link_flags; /* HN_LINK_FLAG_ */
|
|
|
|
|
|
|
|
|
|
uint32_t hn_caps; /* HN_CAP_ */
|
|
|
|
|
uint32_t hn_flags; /* HN_FLAG_ */
|
2016-12-12 00:18:03 -05:00
|
|
|
u_int hn_pollhz;
|
|
|
|
|
|
2016-10-27 01:13:00 -04:00
|
|
|
void *hn_rxbuf;
|
|
|
|
|
uint32_t hn_rxbuf_gpadl;
|
|
|
|
|
struct hyperv_dma hn_rxbuf_dma;
|
|
|
|
|
|
|
|
|
|
uint32_t hn_chim_gpadl;
|
|
|
|
|
struct hyperv_dma hn_chim_dma;
|
|
|
|
|
|
|
|
|
|
uint32_t hn_rndis_rid;
|
|
|
|
|
uint32_t hn_ndis_ver;
|
|
|
|
|
int hn_ndis_tso_szmax;
|
|
|
|
|
int hn_ndis_tso_sgmin;
|
2016-11-21 00:00:51 -05:00
|
|
|
uint32_t hn_rndis_agg_size;
|
|
|
|
|
uint32_t hn_rndis_agg_pkts;
|
|
|
|
|
uint32_t hn_rndis_agg_align;
|
2016-10-27 01:13:00 -04:00
|
|
|
|
|
|
|
|
int hn_rss_ind_size;
|
2017-09-19 02:29:38 -04:00
|
|
|
uint32_t hn_rss_hash; /* setting, NDIS_HASH_ */
|
|
|
|
|
uint32_t hn_rss_hcap; /* caps, NDIS_HASH_ */
|
2016-10-27 01:13:00 -04:00
|
|
|
struct ndis_rssprm_toeplitz hn_rss;
|
2017-01-24 04:24:14 -05:00
|
|
|
|
|
|
|
|
eventhandler_tag hn_ifaddr_evthand;
|
|
|
|
|
eventhandler_tag hn_ifnet_evthand;
|
2017-07-23 23:52:32 -04:00
|
|
|
eventhandler_tag hn_ifnet_atthand;
|
|
|
|
|
eventhandler_tag hn_ifnet_dethand;
|
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
2017-08-09 01:59:45 -04:00
|
|
|
eventhandler_tag hn_ifnet_lnkhand;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Transparent VF delayed initialization.
|
|
|
|
|
*/
|
|
|
|
|
int hn_vf_rdytick; /* ticks, 0 == ready */
|
|
|
|
|
struct taskqueue *hn_vf_taskq;
|
|
|
|
|
struct timeout_task hn_vf_init;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Saved information for VF under transparent mode.
|
|
|
|
|
*/
|
|
|
|
|
void (*hn_vf_input)
|
|
|
|
|
(struct ifnet *, struct mbuf *);
|
|
|
|
|
int hn_saved_caps;
|
|
|
|
|
u_int hn_saved_tsomax;
|
|
|
|
|
u_int hn_saved_tsosegcnt;
|
|
|
|
|
u_int hn_saved_tsosegsz;
|
2016-10-27 01:13:00 -04:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#define HN_FLAG_RXBUF_CONNECTED 0x0001
|
|
|
|
|
#define HN_FLAG_CHIM_CONNECTED 0x0002
|
|
|
|
|
#define HN_FLAG_HAS_RSSKEY 0x0004
|
|
|
|
|
#define HN_FLAG_HAS_RSSIND 0x0008
|
|
|
|
|
#define HN_FLAG_SYNTH_ATTACHED 0x0010
|
2016-11-21 00:21:15 -05:00
|
|
|
#define HN_FLAG_NO_SLEEPING 0x0020
|
2016-11-28 00:23:57 -05:00
|
|
|
#define HN_FLAG_RXBUF_REF 0x0040
|
|
|
|
|
#define HN_FLAG_CHIM_REF 0x0080
|
2017-07-31 22:45:54 -04:00
|
|
|
#define HN_FLAG_RXVF 0x0100
|
2016-11-28 00:23:57 -05:00
|
|
|
|
|
|
|
|
#define HN_FLAG_ERRORS (HN_FLAG_RXBUF_REF | HN_FLAG_CHIM_REF)
|
2016-11-21 00:21:15 -05:00
|
|
|
|
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
2017-08-09 01:59:45 -04:00
|
|
|
#define HN_XVFFLAG_ENABLED 0x0001
|
|
|
|
|
#define HN_XVFFLAG_ACCBPF 0x0002
|
|
|
|
|
|
2016-11-21 00:21:15 -05:00
|
|
|
#define HN_NO_SLEEPING(sc) \
|
|
|
|
|
do { \
|
|
|
|
|
(sc)->hn_flags |= HN_FLAG_NO_SLEEPING; \
|
|
|
|
|
} while (0)
|
|
|
|
|
|
|
|
|
|
#define HN_SLEEPING_OK(sc) \
|
|
|
|
|
do { \
|
|
|
|
|
(sc)->hn_flags &= ~HN_FLAG_NO_SLEEPING; \
|
|
|
|
|
} while (0)
|
|
|
|
|
|
|
|
|
|
#define HN_CAN_SLEEP(sc) \
|
|
|
|
|
(((sc)->hn_flags & HN_FLAG_NO_SLEEPING) == 0)
|
2016-10-27 01:13:00 -04:00
|
|
|
|
|
|
|
|
#define HN_CAP_VLAN 0x0001
|
|
|
|
|
#define HN_CAP_MTU 0x0002
|
|
|
|
|
#define HN_CAP_IPCS 0x0004
|
|
|
|
|
#define HN_CAP_TCP4CS 0x0008
|
|
|
|
|
#define HN_CAP_TCP6CS 0x0010
|
|
|
|
|
#define HN_CAP_UDP4CS 0x0020
|
|
|
|
|
#define HN_CAP_UDP6CS 0x0040
|
|
|
|
|
#define HN_CAP_TSO4 0x0080
|
|
|
|
|
#define HN_CAP_TSO6 0x0100
|
|
|
|
|
#define HN_CAP_HASHVAL 0x0200
|
2017-10-10 04:32:03 -04:00
|
|
|
#define HN_CAP_UDPHASH 0x0400
|
2016-10-27 01:13:00 -04:00
|
|
|
|
|
|
|
|
/* Capability description for use with printf(9) %b identifier. */
|
|
|
|
|
#define HN_CAP_BITS \
|
|
|
|
|
"\020\1VLAN\2MTU\3IPCS\4TCP4CS\5TCP6CS" \
|
2017-10-10 04:32:03 -04:00
|
|
|
"\6UDP4CS\7UDP6CS\10TSO4\11TSO6\12HASHVAL\13UDPHASH"
|
2016-10-27 01:13:00 -04:00
|
|
|
|
|
|
|
|
#define HN_LINK_FLAG_LINKUP 0x0001
|
|
|
|
|
#define HN_LINK_FLAG_NETCHG 0x0002
|
2016-08-09 23:11:07 -04:00
|
|
|
|
|
|
|
|
#endif /* !_IF_HNVAR_H_ */
|