Page MenuHomeFreeBSD

hyperv/hn: Fix/enhance receiving path when VF is activated.
ClosedPublic

Authored by sepherosa_gmail.com on Aug 11 2017, 5:40 AM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 12 2024, 4:32 AM
Unknown Object (File)
Feb 5 2024, 2:12 AM
Unknown Object (File)
Jan 30 2024, 1:17 PM
Unknown Object (File)
Jan 26 2024, 8:55 PM
Unknown Object (File)
Dec 20 2023, 6:20 AM
Unknown Object (File)
Dec 17 2023, 11:37 AM
Unknown Object (File)
Dec 13 2023, 12:02 AM
Unknown Object (File)
Oct 18 2023, 9:08 AM
Subscribers
None

Details

Summary
  • 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.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

This revision was automatically updated to reflect the committed changes.