El documento técnico del proveedor dice: 5Mpps sin problema. Ya estoy golpeando una pared a 120kpps. ¿Dónde está el cuello de botella?

El documento técnico de HP en sus adaptadores QLogic (fka Broadcom) NetXtreme II , que incluye la NIC específica que estoy probando, indica (página 7) que su rendimiento de paquete pequeño para paquetes de hasta 256 bytes / paquete es superior a 5,000,000 paquetes / seg.

En mis pruebas con una aplicación en la que desactivé todo el procesamiento, excepto la mera parte de recepción UDP, solo puedo subir hasta 120,000 paquetes / seg. Los paquetes se distribuyen uniformemente en 12 grupos de multidifusión.

Noté que hay un núcleo (de 12 núcleos cada uno en los 2 zócalos) cuya carga aumenta gradualmente cuando aumenta la velocidad de envío UDP y alcanza un máximo de alrededor de 120,000 . Pero no sé qué está haciendo ese núcleo y por qué. No es un cuello de botella de un solo hilo en mi aplicación, porque no importa si ejecuto una sola instancia de la aplicación para todos los grupos de multidifusión, o 12 instancias que manejan 1 grupo de multidifusión cada uno. Así que el cuello de botella no es mi aplicación receptora.

MSI está habilitado (verificado a través de la vista "recursos por tipo" en el administrador de dispositivos ) y RSS también está habilitado en la configuración de NIC, con 8 colas. Entonces, ¿qué se aferra a ese núcleo? Todas las funciones de descarga de NIC están actualmente activadas, pero desactivarlas no ayudó.

Entonces, ¿dónde podría estar el cuello de botella?

Detalles del sistema:

ProLiant BL460c Gen9
Intel Xeon E5-2670 v3 (2 x 12 núcleos)
NIC HP FlexFabric de 10 Gb y 2 puertos 536FLB
Windows 2012 R2

— Eugene Beresovsky
fuente

Probablemente todas las interrupciones rx y tx son manejadas por el mismo núcleo. No sé mucho acerca de Windows, pero debería haber cierta afinidad SMP para configurar con el fin de difundir IRQs uniformemente relevantes.

— Xavier Lucas

RSS también está habilitado en la configuración de NIC, con 8 colas.

Lo que desafortunadamente no significaba que RSS estaba siendo empleado, ya que

netsh int tcp show global

mostró:

TCP Global Parameters
----------------------------------------------
Receive-Side Scaling State : disabled

Después de correr (por cierto sin reiniciar)

netsh int tcp set global rss=enabled

RSS comenzó a funcionar y la carga que anteriormente se acumulaba en ese núcleo pobre ahora se distribuye uniformemente en muchos núcleos en uno de los 2 nodos NUMA.

No he verificado si eso me permitiría manejar las cargas de Mpps anunciadas, pero el techo se levantó lo suficiente como para evaluar lo que necesitaba.

— Eugene Beresovsky
fuente