MFC 322299,322483,322485-322487

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)

git-svn-id: svn://svn.freebsd.org/base/stable/10@322739 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f