Searched hist:272967 (Results 1 - 2 of 2) sorted by relevance
| /freebsd-10.3-release/sys/modules/ixgbe/ | ||
| H A D | Makefile | diff 272967 Sat Oct 11 22:24:35 MDT 2014 adrian MFC r271649 - Disable flow-director support until it's been debugged and verified. The flowdirector feature shares on-chip memory with other things such as the RX buffers. In theory it should be configured in a way that doesn't interfere with the rest of operation. In practice, the RX buffer calculation didn't take the flow-director allocation into account and there'd be overlap. This lead to various garbage frames being received containing what looks like internal NIC state. What _I_ saw was traffic ending up in the wrong RX queues. If I was doing a UDP traffic test with only one NIC ring receiving traffic, everything is fine. If I fired up a second UDP stream which came in on another ring, there'd be a few percent of traffic from both rings ending up in the wrong ring. Ie, the RSS hash would indicate it was supposed to come in ring X, but it'd come in ring Y. However, when the allocation was fixed up, the developers at Verisign still saw traffic stalls. The flowdirector feature ends up fiddling with the NIC to do various attempts at load balancing connections by populating flow table rules based on sampled traffic. It's likely that all of that has to be carefully reviewed and made less "magic". So for now the flow director feature is disabled (which fixes both what I was seeing and what they were seeing) until it's all much more debugged and verified. Tested: * (me) 82599EB 2x10G NIC, RSS UDP testing. * (verisign) not sure on the NIC (but likely 82599), 100k-200k/sec TCP transaction tests. Submitted by: Marc De La Gueronniere <mdelagueronniere@verisign.com> Sponsored by: Verisign, Inc. |
| /freebsd-10.3-release/sys/conf/ | ||
| H A D | files | diff 272967 Sat Oct 11 22:24:35 MDT 2014 adrian MFC r271649 - Disable flow-director support until it's been debugged and verified. The flowdirector feature shares on-chip memory with other things such as the RX buffers. In theory it should be configured in a way that doesn't interfere with the rest of operation. In practice, the RX buffer calculation didn't take the flow-director allocation into account and there'd be overlap. This lead to various garbage frames being received containing what looks like internal NIC state. What _I_ saw was traffic ending up in the wrong RX queues. If I was doing a UDP traffic test with only one NIC ring receiving traffic, everything is fine. If I fired up a second UDP stream which came in on another ring, there'd be a few percent of traffic from both rings ending up in the wrong ring. Ie, the RSS hash would indicate it was supposed to come in ring X, but it'd come in ring Y. However, when the allocation was fixed up, the developers at Verisign still saw traffic stalls. The flowdirector feature ends up fiddling with the NIC to do various attempts at load balancing connections by populating flow table rules based on sampled traffic. It's likely that all of that has to be carefully reviewed and made less "magic". So for now the flow director feature is disabled (which fixes both what I was seeing and what they were seeing) until it's all much more debugged and verified. Tested: * (me) 82599EB 2x10G NIC, RSS UDP testing. * (verisign) not sure on the NIC (but likely 82599), 100k-200k/sec TCP transaction tests. Submitted by: Marc De La Gueronniere <mdelagueronniere@verisign.com> Sponsored by: Verisign, Inc. |
Completed in 401 milliseconds