K 10
svn:author
V 5
sephe
K 8
svn:date
V 27
2017-08-17T03:48:50.978233Z
K 7
svn:log
V 1858
MFC 322483,322485-322487

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

END