Searched hist:324574 (Results 1 - 5 of 5) sorted by relevance
| /freebsd-10-stable/sys/dev/hyperv/netvsc/ | ||
| H A D | hn_rndis.c | diff 324574 Fri Oct 13 02:41:34 MDT 2017 sephe MFC 324489,324516 324489 hyperv/hn: Workaround erroneous hash type observed on WS2016. Background: - UDP 4-tuple hash type is unconditionally enabled in Hyper-V on WS2016, which is _not_ affected by NDIS_OBJTYPE_RSS_PARAMS. - Non-fragment UDP/IPv4 datagrams' hash type is delivered to VM as TCP_IPV4. Currently this erroneous behavior only applies to WS2016/Windows10. Force l3/l4 protocol check, if the RXed packet's hash type is TCP_IPV4, and the Hyper-V is running on WS2016/Windows10. If the RXed packet is UDP datagram, adjust mbuf hash type to UDP_IPV4. Sponsored by: Microsoft 324516 hyperv/hn: Workaround erroneous hash type observed on WS2016 for VF. The background was described in r324489. Sponsored by: Microsoft |
| H A D | hn_nvs.c | diff 324574 Fri Oct 13 02:41:34 MDT 2017 sephe MFC 324489,324516 324489 hyperv/hn: Workaround erroneous hash type observed on WS2016. Background: - UDP 4-tuple hash type is unconditionally enabled in Hyper-V on WS2016, which is _not_ affected by NDIS_OBJTYPE_RSS_PARAMS. - Non-fragment UDP/IPv4 datagrams' hash type is delivered to VM as TCP_IPV4. Currently this erroneous behavior only applies to WS2016/Windows10. Force l3/l4 protocol check, if the RXed packet's hash type is TCP_IPV4, and the Hyper-V is running on WS2016/Windows10. If the RXed packet is UDP datagram, adjust mbuf hash type to UDP_IPV4. Sponsored by: Microsoft 324516 hyperv/hn: Workaround erroneous hash type observed on WS2016 for VF. The background was described in r324489. Sponsored by: Microsoft |
| H A D | ndis.h | diff 324574 Fri Oct 13 02:41:34 MDT 2017 sephe MFC 324489,324516 324489 hyperv/hn: Workaround erroneous hash type observed on WS2016. Background: - UDP 4-tuple hash type is unconditionally enabled in Hyper-V on WS2016, which is _not_ affected by NDIS_OBJTYPE_RSS_PARAMS. - Non-fragment UDP/IPv4 datagrams' hash type is delivered to VM as TCP_IPV4. Currently this erroneous behavior only applies to WS2016/Windows10. Force l3/l4 protocol check, if the RXed packet's hash type is TCP_IPV4, and the Hyper-V is running on WS2016/Windows10. If the RXed packet is UDP datagram, adjust mbuf hash type to UDP_IPV4. Sponsored by: Microsoft 324516 hyperv/hn: Workaround erroneous hash type observed on WS2016 for VF. The background was described in r324489. Sponsored by: Microsoft |
| H A D | if_hn.c | diff 324574 Fri Oct 13 02:41:34 MDT 2017 sephe MFC 324489,324516 324489 hyperv/hn: Workaround erroneous hash type observed on WS2016. Background: - UDP 4-tuple hash type is unconditionally enabled in Hyper-V on WS2016, which is _not_ affected by NDIS_OBJTYPE_RSS_PARAMS. - Non-fragment UDP/IPv4 datagrams' hash type is delivered to VM as TCP_IPV4. Currently this erroneous behavior only applies to WS2016/Windows10. Force l3/l4 protocol check, if the RXed packet's hash type is TCP_IPV4, and the Hyper-V is running on WS2016/Windows10. If the RXed packet is UDP datagram, adjust mbuf hash type to UDP_IPV4. Sponsored by: Microsoft 324516 hyperv/hn: Workaround erroneous hash type observed on WS2016 for VF. The background was described in r324489. Sponsored by: Microsoft |
| H A D | if_hnvar.h | diff 324574 Fri Oct 13 02:41:34 MDT 2017 sephe MFC 324489,324516 324489 hyperv/hn: Workaround erroneous hash type observed on WS2016. Background: - UDP 4-tuple hash type is unconditionally enabled in Hyper-V on WS2016, which is _not_ affected by NDIS_OBJTYPE_RSS_PARAMS. - Non-fragment UDP/IPv4 datagrams' hash type is delivered to VM as TCP_IPV4. Currently this erroneous behavior only applies to WS2016/Windows10. Force l3/l4 protocol check, if the RXed packet's hash type is TCP_IPV4, and the Hyper-V is running on WS2016/Windows10. If the RXed packet is UDP datagram, adjust mbuf hash type to UDP_IPV4. Sponsored by: Microsoft 324516 hyperv/hn: Workaround erroneous hash type observed on WS2016 for VF. The background was described in r324489. Sponsored by: Microsoft |
Completed in 147 milliseconds