ES2856155T3 - Transmisión de mensajes mediante componentes de aceleración configurados para acelerar un servicio - Google Patents

Abstract

Sistema que comprende: un plano (104) de software que incluye múltiples componentes (108) de servidor configurados para ejecutar instrucciones correspondientes a al menos un servicio; un plano (106) de aceleración que incluye múltiples componentes (110, 116) de aceleración configurables para acelerar el al menos un servicio; y una red (120) configurada para interconectar el plano (104) de software y el plano (106) de aceleración, comprendiendo la red (104) un primer conmutador (302) de tipo parte superior del bastidor, TOR, asociado con un primer subconjunto de los múltiples componentes de aceleración, un segundo conmutador (304) TOR asociado con un segundo subconjunto de los múltiples componentes de aceleración, y un tercer conmutador (306) TOR asociado con un tercer subconjunto de los múltiples componentes de aceleración, en el que cualquiera de entre el primer subconjunto de los múltiples componentes de aceleración es configurable para transmitir un mensaje punto-a-punto a cualquiera de entre el segundo subconjunto de los múltiples componentes de aceleración; y en el que cualquiera de entre el primer subconjunto de los múltiples componentes de aceleración está caracterizado por ser configurable para transmitir el mensaje punto-a-punto a cualquiera de entre el tercer subconjunto de los múltiples componentes de aceleración, y en el que cualquiera de entre el segundo subconjunto de los múltiples componentes de aceleración es configurable para difundir el mensaje punto-a-punto a la totalidad del segundo subconjunto de los múltiples componentes de aceleración, y en el que cualquiera de entre el tercer subconjunto de los múltiples componentes de aceleración es configurable para difundir el mensaje punto-a-punto a la totalidad del tercer subconjunto de los múltiples componentes de aceleración.

Description

DESCRIPCIÓN

Transmisión de mensajes mediante componentes de aceleración configurados para acelerar un servicio

Antecedentes

Cada vez más, los usuarios acceden a aplicaciones ofrecidas a través de recursos informáticos, de red y de almacenamiento ubicados en un centro de datos. Estas aplicaciones se ejecutan en un entorno informático distribuido, al que se hace referencia a veces como el entorno informático de la nube. Los servidores informáticos en un centro de datos están interconectados a través de una red y, de esta manera, las aplicaciones que se ejecutan en los servidores informáticos pueden comunicarse entre sí a través de la red. En grandes centros de datos, la comunicación de mensajes entre los servidores informáticos puede incluir la difusión o multidifusión de mensajes desde un servidor informático a varios otros servidores informáticos. La difusión o multidifusión en dichos centros de datos puede usar una parte significativa del ancho de banda disponible para las aplicaciones. A su vez, esto puede degradar el rendimiento de estas aplicaciones ya que experimentan un rendimiento más bajo y una mayor latencia.

De esta manera, existe una necesidad de procedimientos y de sistemas que alivien al menos algunos de estos problemas. El documento US2007/0053356A1 describe un sistema para la planificación de paquetes multidifusión multivelocidad a través de una red de interconexión que tiene múltiples puertos de entrada, múltiples puertos de salida y múltiples colas de entrada, que comprende paquetes multidifusión multivelocidad con ponderación de velocidad, en cada puerto de entrada se hace funcionar de manera no bloqueante mediante la planificación de manera correspondiente a la ponderación de velocidad de paquetes de como máximo tantos paquetes como el número de colas de entrada de cada puerto de entrada a cada puerto de salida. La planificación se realiza de manera que cada paquete de multidifusión se divida y se despliegue a través de no más de dos redes de interconexión y no más de dos tiempos de conmutación. El sistema se hace funcionar a un rendimiento del 100%, de manera que conserve los trabajos, de manera justa y aun así de manera determinista, de esta manera, sin congestionar nunca los puertos de salida. El sistema realiza el arbitraje en solo una iteración, con un aumento de la velocidad mínima matemática en la red de interconexión. El sistema funciona absolutamente sin ningún problema de reordenamiento de paquetes, sin ningún almacenamiento intermedio interno de paquetes en la red de interconexión y, por lo tanto, de una manera realmente separada y distribuida.

Sumario

Según los aspectos de la presente invención, se proporciona un sistema y un procedimiento tal como se definen en las reivindicaciones adjuntas.

En un ejemplo, la presente descripción se refiere a un sistema que comprende un plano de software incluye múltiples componentes de servidor configurados para ejecutar las instrucciones correspondientes a al menos un servicio y un plano de aceleración que incluye múltiples componentes de aceleración configurables para acelerar el al menos un servicio. El sistema puede incluir además una red configurada para interconectar el plano de software y el plano de aceleración, la red puede incluir un primer conmutador de tipo parte superior del bastidor (Top-Of-Rack, TOR) asociado con un primer subconjunto de los múltiples componentes de aceleración, un segundo conmutador TOR asociado con un segundo subconjunto de los múltiples componentes de aceleración, y un tercer conmutador TOR asociado con un tercer subconjunto de los múltiples componentes de aceleración, en el que cualquiera de entre el primer subconjunto de los múltiples componentes de aceleración es configurable para transmitir un mensaje punto-a-punto a cualquiera de entre el segundo subconjunto de los múltiples componentes de aceleración y para transmitir el mensaje punto-a-punto a cualquiera de entre el tercer subconjunto de los múltiples componentes de aceleración, y en el que cualquiera de entre el segundo subconjunto de los múltiples componentes de aceleración es configurable para difundir el mensaje punto-a-punto a la totalidad del segundo subconjunto de los múltiples componentes de aceleración, y en el que cualquiera de entre el tercer subconjunto de los múltiples componentes de aceleración es configurable para difundir el mensaje punto-a-punto a la totalidad del tercer subconjunto de los múltiples componentes de aceleración.

En otro ejemplo, la presente descripción se refiere a un procedimiento para permitir que un primer componente de aceleración de entre una primera pluralidad de componentes de aceleración, asociado con un primer conmutador de tipo parte superior del bastidor (TOR), transmita mensajes a otros componentes de aceleración en un plano de aceleración configurable para proporcionar una aceleración de servicio para al menos un servicio. El procedimiento puede incluir la transmisión por parte del primer componente de aceleración de un mensaje punto-a-punto a un segundo componente de aceleración, asociado con un segundo conmutador TOR diferente del primer conmutador TOR, y a un tercer componente de aceleración, asociado con un tercer conmutador TOR diferente del primer conmutador TOR y del segundo conmutador TOR. El procedimiento puede incluir además la difusión por parte del segundo componente de aceleración del mensaje punto-a-punto a la totalidad de una segunda pluralidad de componentes de aceleración asociados con el segundo conmutador TOR. El procedimiento puede incluir además la difusión por parte del tercer componente de aceleración del mensaje punto-a-punto a la totalidad de una tercera pluralidad de componentes de aceleración asociados con el tercer conmutador TOR.

En todavía otro ejemplo, la presente descripción se refiere a un componente de aceleración para su uso de entre una primera pluralidad de componentes de aceleración, asociados con un primer conmutador de tipo parte superior del bastidor (TOR), para transmitir mensajes a otros componentes de aceleración en un plano de aceleración configurable para proporcionar una aceleración de servicio para al menos un servicio. El componente de aceleración puede incluir un componente de transporte configurado para trasmitir un mensaje punto-a-punto a un segundo componente de aceleración, asociado con un segundo conmutador TOR diferente del primer conmutador TOR, y a un tercer componente de aceleración, asociado con un tercer conmutador TOR diferente del primer conmutador TOR y del segundo conmutador TOR. El componente de transporte puede estar configurado además para difundir un segundo mensaje punto-a-punto a la totalidad de una segunda pluralidad de componentes de aceleración asociados con el segundo conmutador TOR y a la totalidad de una tercera pluralidad de componentes de aceleración asociados con el tercer conmutador TOR.

Este Sumario se proporciona para introducir una selección de conceptos de una manera simplificada que se describen adicionalmente más adelante en la sección Descripción detallada. El Sumario no pretende identificar las características clave o esenciales del objeto que se reivindica, ni tampoco se prevé su uso para limitar el alcance del objeto que se reivindica.

Breve descripción de los dibujos

La presente descripción se ilustra a modo de ejemplo y no está limitada por las figuras adjuntas, en las que los números de referencia similares indican elementos similares. Los elementos en las figuras se ilustran con propósitos de simplicidad y claridad y no se han dibujado necesariamente a escala.

La Fig. 1 es un diagrama de una arquitectura que puede incluir un plano de software y un plano de aceleración según un ejemplo;

La Fig. 2 muestra un diagrama de un sistema para la transmisión de mensajes mediante componentes de aceleración configurados para acelerar un servicio según un ejemplo;

La Fig. 3 muestra un diagrama de un sistema para la transmisión de mensajes mediante componentes de aceleración configurados para acelerar un servicio según un ejemplo;

La Fig. 4 muestra un diagrama de un componente de aceleración según un ejemplo;

La Fig. 5 muestra un diagrama de un conmutador de 3 puertos según un ejemplo;

La Fig. 6 muestra un diagrama de un sistema para la transmisión de mensajes mediante un componente de aceleración configurado para acelerar un servicio según un ejemplo;

La Fig. 7 muestra un diagrama de flujo de un procedimiento para la transmisión de mensajes mediante un componente de aceleración configurado para acelerar un servicio según un ejemplo; y

La Fig. 8 muestra un diagrama de flujo de otro procedimiento para la transmisión de mensajes mediante componentes de aceleración configurados para acelerar un servicio según un ejemplo.

Descripción detallada

Los ejemplos descritos en esta descripción se refieren a procedimientos y a sistemas que permiten la transmisión de mensajes entre componentes de aceleración configurables para acelerar un servicio. Un componente de aceleración incluye, pero no se limita a, un componente de hardware configurable (o configurado) para realizar una función que corresponde a un servicio ofrecido, por ejemplo, por un centro de datos de manera más eficiente que el software que se ejecuta en una unidad central de procesamiento (Central Processing Unit, CPU) de propósito general. Los componentes de aceleración pueden incluir matrices de puertas programables por campo (Field Programmable Gate Arrays, FPGAs), unidades de procesamiento gráfico (Graphics Processing Units, GPUs), circuitos integrados específicos de aplicación (Application Specific Integrated Circuits, ASICs), dispositivos lógicos programables borrables y/o complejos (Erasable and/or Complex Programable Logic Devices, PLDs), dispositivos de matriz lógica programable (Programmable Array Logic, PAL), dispositivos de matriz lógica genérica (Generic Array Logic, GAL) y dispositivos de matriz de procesadores masivamente paralelos (Massively parallel processor Array, MPPA). Puede usarse un archivo de imagen para configurar o reconfigurar componentes de aceleración, tales como FPGAs. La información incluida en un archivo de imagen puede ser usada para programar los componentes de hardware de un componente de aceleración (por ejemplo, bloques lógicos e interconexiones reconfigurables de una FPGA) para implementar la funcionalidad deseada. La funcionalidad deseada puede ser implementada para contribuir a cualquier servicio que pueda ofrecerse a través de una combinación de recursos de computación, de red y de almacenamiento, tal como a través de un centro de datos u otra infraestructura para proporcionar un servicio.

Los aspectos descritos pueden implementarse también en entornos informáticos en la nube. La computación en nube puede hacer referencia a un modelo para permitir un acceso bajo demanda a través de la red a un conjunto compartido de recursos informáticos configurables. Por ejemplo, la computación en nube puede emplearse en el mercado para ofrecer un acceso ubicuo y conveniente bajo demanda al conjunto compartido de recursos informáticos configurables. El conjunto compartido de recursos informáticos configurables puede aprovisionarse rápidamente mediante virtualización y puede lanzarse con poco esfuerzo de gestión o interacción con el proveedor de servicios, y posteriormente puede escalarse según corresponda. Un modelo de computación en la nube puede estar compuesto de varias características tales como, por ejemplo, autoservicio bajo demanda, amplio acceso a red, agrupación de recursos, elasticidad rápida, servicio medido, etc. Un modelo de computación en la nube puede exponer también varios modelos de servicio, tales como, por ejemplo, software como servicio (Software as a Service, "SaaS"), plataforma como servicio (Platform as a Service, "PaaS") e infraestructura como servicio (Infrastructure as a Service, "IaaS"). Un modelo de computación en la nube puede implementarse también usando diferentes modelos de implementación, tales como nube privada, nube comunitaria, nube pública, nube híbrida, etc.

Una implementación de centro de datos puede incluir un plano de aceleración de hardware y un plano de software. El plano de aceleración de hardware puede incluir múltiples componentes de aceleración en red (por ejemplo, FPGAs). El plano de software puede incluir múltiples componentes de servidor implementados como software en red (por ejemplo, unidades centrales de procesamiento (CPUs)). Una infraestructura de red puede ser compartida entre el plano de aceleración de hardware y el plano de software. En algunos entornos, los componentes de servidor implementados en software están vinculados localmente a componentes de aceleración correspondientes. Los componentes de aceleración pueden comunicarse entre sí a través de un protocolo de red. Para proporcionar un servicio fiable a un usuario del servicio ofrecido a través de un centro de datos, puede requerirse que cualquiera de los mecanismos de comunicación cumpla ciertos requisitos de rendimiento, incluyendo la fiabilidad. En ciertos ejemplos, la presente descripción permite una capa de transporte ligera para cumplir dichos requisitos. En un ejemplo, los componentes de aceleración pueden comunicarse entre sí a través de una capa de transporte ligera (Lightweight Transport Layer, LTL).

La Fig. 1 muestra una arquitectura 100 que puede incluir un plano 104 de software y un plano 106 de aceleración según un ejemplo. El plano 104 de software puede incluir una colección de componentes de servidor accionados por software (cada uno indicado mediante el símbolo "S") mientras que el plano de aceleración puede incluir una colección de componentes de aceleración (cada uno indicado mediante el símbolo "A"). En este ejemplo, cada componente de servidor puede corresponder a un ordenador servidor que ejecuta instrucciones legibles por máquina usando una o más unidades de procesamiento central (CPUs). En un ejemplo, estas instrucciones pueden corresponder a un servicio, tal como un servicio de búsqueda de texto/imagen/vídeo, un servicio de traducción o cualquier otro servicio que puede ser configurado para proporcionar un resultado útil a un usuario de un dispositivo. Cada CPU puede ejecutar las instrucciones correspondientes a los diversos componentes (por ejemplo, módulos de software o bibliotecas) del servicio. Cada componente de aceleración puede incluir lógica de hardware para implementar funciones, tales como, por ejemplo, partes de servicios ofrecidos por un centro de datos.

El plano 106 de aceleración puede construirse usando una colección heterogénea u homogénea de componentes de aceleración, que incluyen diferentes tipos de componentes de aceleración y/o el mismo tipo de componentes de aceleración con diferentes capacidades. Por ejemplo, el plano 106 de aceleración puede incluir matrices de puertas programables por campo (FPGAs), circuitos integrados específicos de aplicación (ASICs), productos estándar específicos de aplicación (ASSPs), sistemas de sistema en un chip (System-on-a-chip, SOC), dispositivos lógicos programables complejos (CPLDs), otros tipos de dispositivos lógicos de hardware programables, etc. El plano 106 de aceleración puede proporcionar un tejido reconfigurable de componentes de aceleración.

Un componente de servidor puede ser generalmente cualquier componente de computación que pueda realizar operaciones usando cada uno de sus subprocesos de hardware de CPU para ejecutar instrucciones legibles por máquina. Un componente de aceleración puede realizar operaciones usando varios elementos lógicos paralelos para realizar tareas computacionales. Como ejemplo, una FPGA puede incluir varias matrices de puertas que pueden estar configuradas para realizar ciertas tareas computacionales en paralelo. De esta manera, un componente de aceleración puede realizar algunas operaciones en menos tiempo en comparación con un componente de servidor accionado por software. En el contexto de la arquitectura 100, la "aceleración" refleja su potencial para acelerar las funciones que son realizadas por los componentes de servidor.

En un ejemplo, la arquitectura 100 puede corresponder a un entorno de centro de datos que incluye un gran número de servidores. Los servidores pueden corresponder a los componentes de servidor en el plano 104 de software. En otro ejemplo, la arquitectura 100 puede corresponder a un sistema empresarial. En otro ejemplo, la arquitectura 100 puede corresponder a un dispositivo o aparato de usuario que usa al menos un componente de servidor que tiene acceso a dos o más componentes de aceleración. De hecho, dependiendo de los requisitos de un servicio, también son posibles otras implementaciones para la arquitectura 100.

La red 120 puede acoplar los componentes de servidor en el plano 104 de software a los otros componentes de servidor y acoplar los componentes de aceleración en el plano 106 de aceleración a otros componentes de aceleración. En este ejemplo, los componentes de servidor pueden usar la red 120 para interactuar entre sí y los componentes de aceleración pueden usar la red 120 para interactuar entre sí. La interacción entre los componentes de servidor en el plano 104 de software puede ser independiente de la interacción entre los componentes de aceleración en el plano 106 de aceleración. En este ejemplo, dos o más componentes de aceleración pueden comunicarse de manera transparente con relación a los componentes de servidor en el plano 104 de software, fuera de la dirección de los componentes de servidor, y sin que los componentes de servidor sean "conscientes" de que se produce una interacción particular en el plano 106 de aceleración.

La arquitectura 100 puede usar cualquiera de entre una diversidad de protocolos diferentes para facilitar la comunicación entre los componentes de aceleración a través de la red 120 y puede usar cualquiera de entre una diversidad de protocolos diferentes para facilitar la comunicación entre los componentes de servidor a través de la red 120. Por ejemplo, la arquitectura 100 puede usar el protocolo Ethernet para transmitir paquetes de protocolo de Internet (Internet Protocol, IP) a través de la red 120. En una implementación, a cada componente de servidor local en un servidor se le proporciona una única dirección IP física. El componente de aceleración local en el mismo servidor puede adoptar la misma dirección IP. El servidor puede determinar de diferentes maneras si un paquete entrante está destinado al componente de servidor local o está destinado al componente de aceleración local. Por ejemplo, los paquetes que están destinados al componente de aceleración local pueden formularse como paquetes UDP que tienen un puerto específico; por otra parte, es posible que los paquetes definidos por el servidor no se formulen de esta manera. En otro ejemplo, los paquetes que pertenecen al plano 106 de aceleración pueden distinguirse de los paquetes que pertenecen al plano 104 de software en base al valor de un indicador de estado en cada uno de los paquetes. En un ejemplo, la arquitectura 100 puede considerarse como dos redes lógicas (plano 104 de software y plano 106 de aceleración) que pueden compartir los mismos enlaces de comunicación de red física. Los paquetes asociados con las dos redes lógicas pueden distinguirse unos de otros por sus clases de tráfico respectivas.

En otro aspecto, cada componente de servidor en la arquitectura 100 está acoplado a al menos un componente de aceleración en el plano 104 de aceleración a través de un enlace local. Por ejemplo, un componente de servidor y un componente de aceleración pueden disponerse juntos y pueden mantenerse como una única unidad utilizable (por ejemplo, un servidor) en el interior de la arquitectura 100. En esta disposición, puede hacerse referencia al servidor como el componente de servidor "local" para distinguirlo de otros componentes de servidor que están asociados con otros servidores. De manera similar, puede hacerse referencia al componente o a los componentes de aceleración de un servidor como componente o componentes de aceleración "locales" para distinguirlos de otros componentes de aceleración que están asociados con otros servidores.

Tal como se muestra en la arquitectura 100, el componente 108 de servidor puede acoplar al componente 110 de aceleración a través del enlace 112 local (por ejemplo, un enlace interconexión rápida de componentes periféricos (Peripheral Component Interconnect Express, PCIe)). De esta manera, el componente 108 de servidor puede ser un componente de servidor local desde la perspectiva del componente 110 de aceleración y el componente 110 de aceleración puede ser un componente de aceleración local desde la perspectiva del componente 108 de servidor. El enlace local del componente 108 de servidor y el componente 110 de aceleración puede formar parte de un servidor. De manera más general, los componentes de servidor en el plano 104 de software pueden acoplarse localmente a los componentes de aceleración en el plano 106 de aceleración a través de muchos enlaces individuales representados colectivamente como un acoplamiento 114 local^A-a-local^S. En este ejemplo, un componente de servidor puede interactuar directamente con cualquier componente de aceleración vinculado localmente. Un componente de servidor puede iniciar una comunicación con un componente de aceleración vinculado localmente para causar una comunicación adicional entre múltiples componentes de aceleración. Por ejemplo, un componente de servidor puede emitir una solicitud para un servicio (o parte del mismo) en el que la funcionalidad del servicio *o parte del mismo) está distribuida en un grupo de uno o más componentes de aceleración en el plano 106 de aceleración. Un componente de servidor puede interactuar también indirectamente con otros componentes de aceleración en el plano 106 de aceleración a los que el componente de servidor no está vinculado localmente. Por ejemplo, el componente 108 de servidor puede comunicarse indirectamente con el componente 116 de aceleración mediante el componente 110 de aceleración. En este ejemplo, el componente 110 de aceleración se comunica con el componente 116 de aceleración a través de un enlace 118 de una red (por ejemplo, la red 120).

Los componentes de aceleración en el plano 106 de aceleración pueden usarse de manera ventajosa para acelerar servicios a mayor escala de manera robusta en un centro de datos. Partes sustanciales de servicios de centros de datos complejos pueden asignarse a componentes de aceleración (por ejemplo, FPGAs) mediante el uso de interconexiones de baja latencia para cálculos que abarcan múltiples componentes de aceleración. Los componentes de aceleración pueden reconfigurarse también según corresponda para proporcionar una funcionalidad de servicio diferente en diferentes momentos. Aunque la Fig. 1 muestra un cierto número de componentes de arquitectura 100 dispuestos de una manera determinada, podría haber más o menos componentes dispuestos de manera diferente. Además, varios componentes de arquitectura 100 pueden implementarse usando también otras tecnologías.

La Fig. 2 muestra un diagrama de un sistema 200 para la transmisión o retransmisión de mensajes por parte de componentes de aceleración configurados para acelerar un servicio según un ejemplo. En un ejemplo, el sistema 200 puede implementarse como un bastidor de servidores en un centro de datos. Los servidores 204, 206 y 208 pueden estar incluidos en un bastidor en el centro de datos. Cada uno de los servidores 204, 206 y 208 puede acoplar al conmutador 210 de tipo parte superior del bastidor (TOR). Otros bastidores, aunque no se muestran, pueden tener una configuración similar. El servidor 204 puede incluir además un componente 212 de servidor que incluye CPUs 214, 216, etc. El componente 212 de servidor, junto con los componentes de servidor de los servidores 206 y 208, puede incluirse en el plano 104 de software. El servidor 204 puede incluir también un componente 218 de aceleración. El componente 218 de aceleración, junto con los componentes de aceleración desde los servidores 206 y 208, puede incluirse en el plano 106 de aceleración.

El componente 218 de aceleración puede acoplarse directamente a un componente 212 de servidor a través de un enlace 220 local (por ejemplo, un enlace PCIe). De esta manera, el componente 218 de aceleración puede ver el componente 212 de servidor como un componente de servidor local. El componente 218 de aceleración y el componente 212 de servidor pueden estar acoplados también indirectamente por medio del controlador 222 de interfaz de red (por ejemplo, usado para comunicarse a través de la infraestructura 120 de red). En este ejemplo, el servidor 204 puede cargar imágenes que representan la funcionalidad del servicio en el componente 218 de aceleración.

El componente 218 de aceleración puede acoplarse también al conmutador 210 TOR. Por lo tanto, en el sistema 200, el componente 218 de aceleración puede representar la ruta a través de la cual el componente 212 de servidor interactúa con otros componentes en el centro de datos (incluyendo otros componentes de servidor y otros componentes de aceleración). El sistema 200 permite que los componentes 218 de aceleración realicen el procesamiento (por ejemplo, realizando una encriptación, compresión, etc.) de los paquetes que se reciben desde el conmutador 210 TOR (y/o se envían al mismo), sin dificultar las operaciones basadas en CPU realizadas por el componente 212 de servidor. Aunque la Fig. 2 muestra un determinado número de componentes del sistema 200 dispuestos de determinada manera, podría haber más o menos componentes dispuestos de manera diferente. Además, varios componentes del sistema 200 pueden implementarse usando también otras tecnologías.

La Fig. 3 muestra un diagrama de un sistema 300 para la transmisión o retransmisión de mensajes por parte de componentes de aceleración configurados para acelerar un servicio según un ejemplo. En este ejemplo, el enrutamiento IP puede usarse para transmitir o recibir mensajes entre conmutadores TOR, incluyendo el conmutador 1 302 TOR, el conmutador 2304 TOR y el conmutador N 306 TOR. Cada servidor o grupo de servidores puede tener una única dirección IP "física" que puede ser proporcionada por el administrador de red. De esta manera, en este ejemplo, cada uno de entre el grupo 1320 de servidores, el grupo 2322 de servidores y el grupo N 324 de servidores puede incluir servidores, donde cada uno de los mismos puede tener una dirección IP "física". Los componentes de aceleración pueden usar la IP física de su servidor como su dirección. Para distinguir entre los paquetes IP destinados para el servidor de los paquetes destinados para un componente de aceleración, pueden usarse paquetes UDP, con un puerto específico para designar el componente de aceleración como destino. Un componente de aceleración puede transmitir un mensaje a un conjunto seleccionado de componentes de aceleración asociados con diferentes conmutadores TOR usando la funcionalidad de la capa 3 correspondiente al modelo de interconexión de sistemas abiertos (Open Systems Interconnections, OSI) de siete capas. La funcionalidad de la capa 3 puede ser similar a la proporcionada por la capa de red del modelo OSI. En este ejemplo, un componente de aceleración puede transmitir un mensaje punto-a-punto a cada uno de los otros componentes de aceleración relevantes asociados con los conmutadores TOR respectivos. A continuación, esos componentes de aceleración pueden usar un paquete de difusión Ethernet de la capa 2 para enviar los datos a todos los componentes de aceleración asociados con el conmutador TOR. La funcionalidad de la capa 2 puede ser similar a la proporcionada por la capa de enlace de datos del modelo OSI. La funcionalidad de la capa 2 puede incluir control de acceso al medio, el control de flujo y la comprobación de errores. En un ejemplo, esta etapa no requerirá ningún soporte de transmisión desde una red que interconecta el plano de aceleración y el plano de software. Esto puede aliviar, de manera ventajosa, la necesidad de la funcionalidad multidifusión proporcionada por los enrutadores u otras infraestructuras de red. A su vez, esto puede reducir la complejidad de implementar y administrar componentes de aceleración. Además, en general, los niveles más altos de la red (por ejemplo, la red que incluye enrutadores y otros conmutadores TOR) pueden presentar demasiadas suscripciones, lo que, a su vez, puede reducir el ancho de banda disponible para los componentes de aceleración que se comunican usando la red superior. Por le contrario, en este ejemplo, de manera ventajosa, los componentes de aceleración que comparten un conmutador TOR pueden tener disponible un mayor ancho de banda para cualquier transmisión de mensajes desde un componente de aceleración a otro.

La Fig. 4 muestra un diagrama de un componente 400 de aceleración según un ejemplo. El componente 400 de aceleración puede estar incluido en el plano 106 de aceleración. Los componentes incluidos en el componente 400 de aceleración pueden implementarse en recursos de hardware (por ejemplo, bloques lógicos e interconexiones programables) del componente 400 de aceleración.

El componente 400 de aceleración puede incluir una lógica 406 de aplicación, una soft shell 404 asociada con un primer conjunto de recursos y una shell 402 asociada con un segundo conjunto de recursos. Los recursos asociados con la shell 402 pueden corresponder a componentes relacionados con la interfaz de nivel inferior que generalmente pueden ser los mismos en muchos escenarios de aplicación diferentes. Los recursos asociados con la soft shell 404 pueden ser los mismos en al menos algunos escenarios de aplicación diferentes. La lógica 406 de aplicación puede conceptualizarse además como que incluye un dominio de aplicación (por ejemplo, un "rol "). El dominio o rol de aplicación puede representar una parte de la funcionalidad incluida en un servicio compuesto distribuido entre múltiples componentes de aceleración. Los roles en cada componente de aceleración en un grupo de componentes de aceleración pueden vincularse entre sí para crear un grupo que proporcione la aceleración de servicio para el dominio de aplicación.

El dominio de aplicación aloja la lógica 406 de aplicación que realiza tareas específicas del servicio (tales como una parte de la funcionalidad para clasificar documentos, encriptar datos, comprimir datos, facilitar visión por ordenador, facilitar traducción de voz, aprendizaje automático, etc.). Los recursos asociados con la soft shell 404 generalmente son menos propensos a cambios en comparación con los recursos de aplicación, y los recursos asociados con la shell 402 son menos propensos a cambios en comparación con los recursos asociados con la soft shell 404 (aunque es posible cambiar (reconfigurar) cualquier componente del componente 400 de aceleración).

Durante el funcionamiento, en este ejemplo, la lógica 406 de aplicación interactúa con los recursos de la shell y los recursos de la soft shell de manera análoga a la manera en la que una aplicación implementada en software interactúa con los recursos del sistema operativo subyacente. Desde el punto de vista del desarrollo de aplicaciones, el uso de recursos de shell y recursos de soft shell comunes libera al desarrollador de tener que recrear estos componentes comunes para cada servicio.

Con referencia en primer lugar a la shell 402, los recursos de la shell pueden incluir un puente 408 para acoplar el componente 400 de aceleración al controlador de interfaz de red (mediante una interfaz 410 NIC) y un conmutador local en la parte superior del bastidor (a través de una interfaz 412 TOR). El puente 408 incluye también una ruta de datos que permite que el tráfico desde la NIC o TOR fluya al componente 400 de aceleración y que el tráfico desde el componente 400 de aceleración fluya a la NIC o TOR. Internamente, el puente 408 puede estar compuesto de varios FIFOs (414, 416) que almacenan en memoria intermedia los paquetes recibidos, y varios selectores y lógica de arbitraje que enrutan los paquetes a sus destinos deseados. Un componente 418 de control de derivación, cuando está activado, puede controlar el puente 408 de manera que los paquetes se transmitan entre NIC y TOR sin procesamiento adicional por parte del componente 400 de aceleración.

El controlador 420 de memoria gobierna la interacción entre el componente 400 de aceleración y la memoria 422 local (tal como la memoria DRAM). El controlador 420 de memoria puede realizar una corrección de errores como parte de sus servicios.

La interfaz 424 de servidor puede proporcionar una funcionalidad que permite que el componente 400 de aceleración interactúe con un componente de servidor local (no mostrado). En una implementación, la interfaz 424 de servidor puede usar una interconexión rápida de componentes periféricos (PCIe), junto con acceso directo a memoria (Direct Memory Access, DMA), para intercambiar información con el componente de servidor local. La shell exterior puede incluir también varias características 426 diferentes, tales como generadores de señales de reloj, LEDs de estado, funcionalidad de corrección de errores, etc.

Puede usarse un enrutador 428 elástico para enrutar mensajes entre diversos componentes internos del componente 400 de aceleración, y entre el componente de aceleración y entidades externas (por ejemplo, a través de un componente 430 de transporte). Cada uno de estos extremos puede estar asociado con un puerto respectivo. Por ejemplo, el enrutador 428 elástico está acoplado al controlador 420 de memoria, a la interfaz 424 de servidor, a la lógica 406 de aplicación y al componente 430 de transporte.

El componente 430 de transporte puede formular los paquetes para su transmisión a entidades remotas (tales como otros componentes de aceleración) y para recibir paquetes desde entidades remotas (tales como otros componentes de aceleración). En este ejemplo, un conmutador 432 de 3 puertos, cuando está activado, realiza la función del puente 408 enrutando paquetes entre NIC y TOR, y entre NIC o TOR y un puerto local asociado con el componente 400 de aceleración.

Un registrador 434 de diagnósticos puede almacenar información relacionada con las operaciones realizadas por el enrutador 428, el componente 430 de transporte y el conmutador 432 de 3 puertos en una memoria intermedia circular. Por ejemplo, la información puede incluir datos sobre acerca del origen y de las direcciones IP de destino de un paquete, datos específicos del servidor o marcas de tiempo. El registro puede almacenarse como parte de un sistema de telemetría (no mostrado) de manera que un técnico pueda estudiar el registro para diagnosticar causas de un fallo o de un rendimiento subóptimo en el componente 400 de aceleración.

Pueden incluirse múltiples componentes de aceleración, como el componente 400 de aceleración, en el plano 106 de aceleración. Los componentes de aceleración pueden usar diferentes topologías de red (en lugar de usar la red 120 para la comunicación) para comunicarse unos con otros. En un aspecto, los componentes de aceleración están conectados directamente unos con otros, tal como, por ejemplo, en un toro bidimensional. Aunque la Fig. 4 muestra un determinado número de componentes del componente 400 de aceleración dispuestos de manera determinada, podría haber más o menos componentes dispuestos de manera diferente. Además, varios componentes del componente 400 de aceleración pueden implementarse usando también otras tecnologías.

La Fig. 5 muestra un diagrama de un conmutador 500 de 3 puertos según un ejemplo (las líneas continuas representan rutas de datos y las líneas discontinuas representan señales de control). El conmutador 500 de 3 puertos puede proporcionar funciones para prevenir que los paquetes para los componentes de aceleración sean enviados al sistema servidor. Si la red de datos admite diversas clases de tráfico sin pérdida, el conmutador 500 de 3 puertos puede configurarse para proporcionar soporte suficiente para almacenar en memoria intermedia y pausar los flujos entrantes sin pérdida para permitir al mismo insertar su propio tráfico en la red. Para soportar esto, el conmutador 500 de 3 puertos puede configurarse para distinguir las clases de tráfico sin pérdidas (por ejemplo, acceso directo a memoria remota (Remote Direct Memory Access, RDMA)) de las clases de flujos con pérdidas (por ejemplo, TCP/IP). Un campo en la cabecera de un paquete puede ser usado para identificar a qué clase de tráfico pertenece el paquete. Puede usarse una memoria 530 de configuración para almacenar cualquier archivo de configuración o estructura de datos correspondientes al conmutador 500 de 3 puertos.

El conmutador 500 de 3 puertos puede tener un primer puerto 502 (lado del servidor) para conectarse a un primer MAC y un segundo puerto 504 (lado de la red) para conectarse a un segundo MAC. Un tercer puerto local puede proporcionar un servicio interno a un componente de transporte (por ejemplo, el componente 430 de transporte). El conmutador 500 de 3 puertos puede funcionar generalmente como un conmutador de red, con algunas limitaciones. Específicamente, el conmutador 500 de 3 puertos puede estar configurado para dejar pasar los paquetes recibidos en el puerto local (por ejemplo, paquetes de capa de transporte ligero (LTL)) solo al segundo puerto 504 (no al primer puerto 502). De manera similar, el conmutador 500 de 3 puertos puede estar diseñado para no suministrar los paquetes desde el primer puerto 502 al puerto local.

El conmutador 500 de 3 puertos puede tener dos memorias intermedias de paquetes: una para el primer puerto 502 de recepción (Rx) y otro para el segundo puerto 504 de recepción. Las memorias intermedias de paquetes pueden dividirse en varias regiones. Cada región puede corresponder a una clase de tráfico de paquetes. A medida que llegan los paquetes y se extraen de sus tramas (por ejemplo, tramas de Ethernet), pueden ser clasificados por clasificadores de paquetes (por ejemplo, un clasificador 520 de paquetes y clasificador 522 de paquetes) en una de las clases de paquetes disponibles (con pérdida, sin pérdida, etc.) y pueden escribirse en una memoria intermedia de paquetes correspondiente. Si no hay espacio de memoria intermedia disponible para un paquete entrante, entonces el paquete puede descartarse. Una vez que un paquete está almacenado y preparado para ser transmitido, un elemento de arbitraje (por ejemplo, elemento 512 de arbitraje o elemento 514 de arbitraje) puede realizar una selección de entre los paquetes disponibles y puede transmitir el paquete. Un bloque de inserción de control de flujo de prioridad (Priority Flow Control, PFC) (por ejemplo, inserción 526 PFC o inserción 528 PFC) puede permitir que el conmutador 500 de 3 puertos inserte tramas PFC entre paquetes de flujo en la mitad de transmisión de cualquiera de los puertos 502, 504.

El conmutador 500 de 3 puertos puede gestionar una clase de tráfico sin pérdidas como se indica a continuación. Todos los paquetes que llegan en la mitad de la recepción del primer puerto 502 y en la mitad de la recepción del segundo puerto 504 deberían transmitirse eventualmente en las mitades de transmisión (Tx) correspondientes de los puertos. Los paquetes pueden enrutarse siguiendo un esquema de tipo almacenar y reenviar. Puede implementarse un control de flujo de prioridad (PFC) para evitar la pérdida de paquetes. Para las clases de tráfico sin pérdidas, el conmutador 500 de 3 puertos puede generar mensajes PFC y enviar los mismos en las partes de transmisión de los puertos 502 y 504 primero y segundo. En una realización, los mensajes PFC se envían cuando una memoria intermedia de paquetes se llena. Cuando una memoria intermedia está llena o prácticamente llena, se envía un mensaje PFC a la otra parte en el enlace solicitando que se pause el tráfico de esa clase. También pueden recibirse mensajes PFC y puede actuar sobre los mismos. Si se recibe una trama de control PFC para una clase de tráfico sin pérdidas en la parte de recepción de los puertos (502 o 504) primero o segundo, el conmutador 500 de 3 puertos puede suspender el envío de paquetes en la parte de transmisión del puerto que ha recibido la trama de control. Los paquetes pueden almacenarse internamente en memoria intermedia hasta que las memorias intermedias estén llenas, en cuyo momento se generará una trama PFC para la otra parte en el enlace.

El conmutador 500 de 3 puertos puede gestionar una clase de tráfico con pérdida como se indica a continuación. El tráfico con pérdidas (todo lo que no se clasifique como sin pérdidas) puede reenviarse según un esquema de tipo mejor esfuerzo. El conmutador 500 de 3 puertos tiene libertar para descartar paquetes si se produce una congestión.

Pueden detectarse signos de congestión en los paquetes o en los flujos antes de que los paquetes atraviesen un servidor y su pila de red. Por ejemplo, si se detecta un marcador de congestión en un paquete en su ruta hacia el servidor, el componente de transporte puede detener o iniciar rápidamente el flujo, aumentar o disminuir el ancho de banda disponible, regular otros flujos/conexiones, etc., antes de que los efectos de la congestión empiecen a manifestarse en el servidor.

La Fig. 6 muestra un componente 600 de transporte (un ejemplo correspondiente al componente 430 de transporte de la Fig. 4) acoplado a un conmutador 602 de 3 puertos (un ejemplo correspondiente al conmutador 432 de 3 puertos de la Fig. 4) y un enrutador 604 elástico según un ejemplo. El componente 600 de transporte puede estar configurado para actuar como un nodo autónomo en una red. En una realización, el componente 600 de transporte puede estar configurado en el interior de un entorno o una shell en cuyo interior pueden instanciarse procesos o unidades de ejecución arbitrarios. El uso del componente 600 de transporte puede ser ventajoso, debido a la proximidad entre la lógica de aplicación y la red, y la eliminación de las cargas asociadas con el servidor, tales como la navegación por una pila de red compleja, la gestión de interrupciones y la compartición de recursos. De esta manera, las aplicaciones o servicios que usan componentes de aceleración con componentes de transporte, tales como el componente 600 de transporte, pueden ser capaces de comunicarse con latencias más bajas y rendimientos más altos. El propio componente 600 de transporte puede ser un agente que genera y consume tráfico de red para sus propios propósitos.

El componente 600 de transporte puede usarse para implementar la funcionalidad asociada con el mecanismo o el protocolo para intercambiar datos, incluyendo la transmisión o la retransmisión de mensajes. En este ejemplo, el componente 600 de transporte puede incluir lógica 610 de transmisión, lógica 612 de recepción, soft shell 614, lógica 616 de gestión de conexiones, memoria 618 de configuración, memoria 620 intermedia de transmisión y memoria 622 intermedia de recepción. Estos elementos pueden operar para proporcionar una comunicación eficiente y fiable entre los componentes de transporte que pueden estar incluidos como parte de los componentes de aceleración.

En un ejemplo, el componente 600 de transporte puede ser usado para implementar la funcionalidad asociada con la capa de transporte ligero (LTL). De manera consistente con este ejemplo de LTL, el componente 600 de transporte puede exponer dos interfaces principales para LTL: una para la comunicación con el conmutador 602 de 3 puertos (por ejemplo, una interfaz de red local que entonces puede conectarse a un conmutador de red, tal como un conmutador TOR) y la otra para la comunicación con el enrutador 604 elástico (por ejemplo, una interfaz de enrutador elástico). En este ejemplo, la interfaz de red local (local_*) puede contener un NeworkStream, Ready y Valid para ambas direcciones Rx y Tx. En este ejemplo, la interfaz de enrutador elástico (enrutador_*) puede exponer una interfaz de tipo FIFO que soporta múltiples canales virtuales y un esquema de control de flujo basado en créditos. El componente 600 de transporte puede configurarse mediante una estructura de datos de configuración (struct) para parámetros controlables en tiempo de ejecución, y puede emitir una estructura de datos de estado (estructura para supervisar el estado por parte de un servidor u otra lógica de soft shell). La Tabla 1 siguiente muestra un ejemplo de la interfaz de módulo de nivel superior LTL.

(Cont.)

La Tabla 2 siguiente muestra parámetros estáticos ejemplares que pueden configurarse para una instancia LTL en tiempo de compilación. Los valores de estos parámetros son simplemente ejemplos y pueden especificar más o menos parámetros.

De esta manera, tal como se ha indicado anteriormente en la Tabla 3, esto configurará memorias intermedias de tamaño MAX VIRTUAL_CHANNELS EXTRA_SFQ_ENTRIES_MTU para la instancia LTL. Los créditos de enrutador elástico (ER_CRÉDITOS) pueden emitirse con una garantía de al menos 1 crédito para cada canal virtual (Virtual Channel, VC) y un número de créditos adicionales calculado de manera dinámica. El componente 600 de transporte puede exponer un puerto de entrada de configuración que establece una serie de valores de tiempo de ejecución. Este puerto de configuración puede definirse como parte de la estructura de datos de la estructura LTLConfiguration. Los campos para una estructura de datos ejemplar se enumeran en la tabla siguiente (Tabla 4):

La funcionalidad correspondiente a los campos, mostrados en la Tabla 4, puede combinarse o separarse adicionalmente. Ciertos campos podrían estar también en una memoria indexada por una dirección o un campo descriptor en la estructura de datos LTLConfiguration struct. De manera similar, una instrucción especial puede proporcionar información relacionada con uno cualquiera de los campos de la Tabla 4 o puede combinar la información de dichos campos. Podrían realizarse otros cambios en la estructura y en el formato de datos LTLConfiguration struct sin apartarse del alcance de la presente descripción.

Como parte de LTL, en un ejemplo, todos los mensajes pueden encapsularse en el interior de tramas IPv4/UDP. La Tabla 5 siguiente muestra un formato de paquete ejemplar para el encapsulamiento de mensajes en dichas tramas. La columna Grupo muestra los diversos grupos de campos en la estructura de paquete. La columna Descripción muestra los campos correspondientes a cada grupo en la estructura de paquete. La columna Tamaño muestra el tamaño en bits de cada campo. La columna Valor proporciona un valor para el campo y, según sea necesario, proporciona una descripción ejemplar del campo relevante.

La funcionalidad correspondiente a los campos, mostrados en la Tabla 5, puede combinarse o separarse adicionalmente. Ciertos campos podrían estar también en una memoria indexada por una dirección o un campo descriptor en el paquete. De manera similar, una instrucción especial puede proporcionar información relacionada con uno cualquiera de los campos de la Tabla 5 o puede combinar la información de dichos campos. Podrían realizarse otros cambios en la estructura y el formato del paquete sin apartarse del alcance de esta descripción.

La lógica 616 de gestión de conexiones puede proporcionar una interfaz de registro para establecer conexiones entre componentes de transporte. La lógica 616 de gestión de conexiones junto con el software (por ejemplo, una soft shell) puede establecer las conexiones antes de que puedan transmitirse o recibirse datos. En un ejemplo, hay dos tablas de conexiones que pueden controlar el estado de las conexiones, la tabla de conexiones de envío (Send Connection Table, SCT) y la tabla de conexiones de recepción (Receive Connection Table, RCT). Cada una de estas tablas puede almacenarse como parte de la memoria 618 de configuración o alguna otra memoria asociada con el componente 600 de transporte. Cada entrada en el SCT, una entrada en la tabla de conexiones de envío (Send Connection Table Entry, SCTE), puede almacenar el número de secuencia actual de un paquete y otro estado de conexión usado para construir paquetes, tal como la dirección MAC de destino. Las solicitudes que llegan desde el enrutador 604 elástico pueden compararse con una SCTE comparando la dirección IP de destino y los campos de canal virtual proporcionados por el enrutador 604 elástico. Como máximo, una conexión puede tener como objetivo un par dirección IP de destino y VC. De esta manera, la tupla {IP, VC} puede ser una clave única (en términos de base de datos) en la tabla. Es posible que haya dos entradas en la tabla con el mismo VC (por ejemplo, {IP: 10.0.0.1, VC: 0} e {IP: 10.0.0.2, VC: 0}). También es posible que haya dos entradas con la misma dirección IP y diferentes VC: {IP: 10.0.0.1, VC: 0} e {IP: 10.0.0.2, VC: 1}. Sin embargo, es posible no permitir dos entradas con el mismo par {IP, VC}. El número de entradas que admite LTL puede configurarse en tiempo de compilación.

El enrutador 604 elástico puede mover datos en Flits, que pueden tener un tamaño de 128B (32B x 4 ciclos). Los mensajes pueden estar compuestos por varios flits, desmarcados por indicadores de inicio y último. En un ejemplo, una vez que el enrutador 604 elástico selecciona un flujo a ser enviado desde un puerto de entrada a un puerto de salida para un canal virtual determinado, el mensaje completo debe ser suministrado antes de que otro mensaje empiece a llegar en el mismo canal virtual. Es posible que la lógica 616 de gestión de conexiones necesite empaquetar mensajes los desde el enrutador 604 elástico en piezas con el tamaño de la unidad máxima de transporte (Maximum Transport Unit, MTU) de la red. Esto puede realizarse almacenando los datos en una memoria intermedia en cada canal virtual hasta que se cumpla una de las siguientes condiciones: (1) se detecta el indicador último en un flit y (2) hay una cantidad de datos equivalente a una MTU (o un tamaño reducido de manera apropiada para adaptarse a los requisitos de cabecera y de alineación). En esta implementación, la MTU para una carga LTL útil puede ser de 1408 bytes. Una vez que se cumple uno de los requisitos, el componente 600 de transporte, mediante la lógica 610 de transmisión, puede intentar enviar ese paquete. Los destinos de los paquetes pueden determinarse mediante una combinación del canal virtual en el que llega el mensaje en la entrada del componente 600 de transporte (desde el enrutador 604 elástico) y una cabecera de mensaje que puede llegar durante el primer ciclo de los mensajes desde el enrutador 604 elástico. Estos dos valores pueden usarse para indexar en la tabla de conexiones de envío, que puede proporcionar la dirección IP de destino y los números de secuencia para la conexión. En este ejemplo, cada paquete transmitido en una conexión determinada debería tener un número de secuencia que es una unidad mayor que el paquete anterior para esa conexión. La única excepción puede ser para las retransmisiones, que pueden retransmitir un paquete descartado o sin acuse de recibo con el mismo número de secuencia con el que se envió originalmente. El primer paquete enviado en una conexión puede tener un número de secuencia establecido a 1. De esta manera, como ejemplo, para una colección de flits que llegan en varios canales virtuales (VCs) al componente 600 de transporte desde el enrutador 604 elástico, los datos pueden almacenarse en memoria intermedia usando memorias intermedias (por ejemplo, la memoria 622 intermedia de recepción) hasta que se haya recibido el final de un mensaje o una cantidad de datos equivalente a una MTU y, a continuación, puede enviarse un paquete. De esta manera, como ejemplo, si se envían 1500B desde el enrutador 604 elástico a al menos una instancia LTL asociada con el componente 600 de transporte como un único mensaje (por ejemplo, múltiples flits en el mismo VC con cero o un indicador LAST), puede generarse al menos un paquete. En este ejemplo, la instancia LTL puede enviar mensajes en cuanto haya almacenado los datos en la memoria intermedia, es decir, NO esperará a un ACK del primer mensaje antes de enviar el siguiente. Puede no haber un tamaño máximo de mensaje. La instancia LTL puede seguir dividiendo un mensaje en paquetes de tamaño de la MTU y transmitirlos en cuanto haya preparados una cantidad de datos equivalente a una MTU. De manera similar, en este ejemplo, no hay en ningún sitio un campo "longitud de mensaje" en los paquetes, solo un tamaño de carga útil para cada paquete. Es posible que el componente 600 de transporte no tenga un conocimiento previo de cuántos datos contendrá un mensaje. Preferiblemente, una instancia LTL asociada con el componente 600 de transporte puede suministrar los flits que llegan que coincidan con una entrada de SCT determinada, en orden, incluso frente a caídas y tiempos de espera. Es posible que los flits que coinciden con diferentes entradas de SCT no tengan garantías de orden.

En este ejemplo, el componente 600 de transporte emitirá un crédito por cada canal virtual y, a continuación, un crédito para cada memoria intermedia compartida. Los créditos se devolverán después de cada flit, excepto cuando un flit termine una memoria intermedia MTU. Esto puede suceder si se recibe un indicador último o cuando un flit contiene el MTU-ésimo byte de un mensaje. Los créditos consumidos de esta manera pueden ser retenidos por el componente 600 de transporte hasta que se acuse recibo del paquete.

En términos de la recepción de los paquetes por una instancia LTL asociada con el componente 600 de transporte, en un ejemplo, los paquetes que llegan desde la red se hacen coincidir con una entrada RCT (RCTE) mediante un campo en la cabecera del paquete. Cada RCTE almacena el último número de secuencia y en qué canal virtual (VC) enviar los paquetes desde el componente 600 de transporte al enrutador 604 elástico. Múltiples entradas en la RCT pueden apuntar al mismo canal virtual de salida. El número de entradas que admite LTL puede configurarse en tiempo de compilación. Cuando los paquetes llegan al puerto local desde el conmutador de red, el componente 600 de transporte puede determinar con qué entrada en la tabla de conexiones de recepción (RCT) se empareja el paquete. Si no existe una tabla RCT coincidente, el paquete puede ser descartado. El componente de transporte puede comprobar que el número de secuencia coincide con el valor esperado desde la entrada RCT. Si el número de secuencia es mayor que la entrada RCT, el paquete puede descartarse. Si el número de secuencia es menor que el que espera la entrada RCT, puede generarse un acuse de recibo (ACK) y el paquete puede ser descartado. Si coincide, el componente de transporte puede tomar el campo de canal virtual de la entrada RCT. Si el número de créditos disponibles del enrutador (ER) elástico para ese canal virtual es suficiente para cubrir el tamaño del paquete, el componente 600 de transporte puede aceptar el paquete. Si no hay suficientes créditos, el componente 600 de transporte puede descartar el paquete. Una vez aceptado el paquete, puede generarse un acuse de recibo (ACK) y puede incrementarse el número de secuencia de la entrada RCT. El enrutador 604 elástico puede usar la cabecera del paquete para determinar el punto de destino final al que está destinado el mensaje. El componente de transporte puede necesitar suficientes créditos para poder transferir la cantidad de datos de un paquete completo al enrutador 604 elástico para seguir avanzando. Para ayudar a garantizar que todos los VCs puedan seguir avanzando, el componente 600 de transporte puede requerir al enrutador 604 elástico que proporcione créditos dedicados para cada VC para gestionar al menos una MTU de datos para cada VC. En este ejemplo, no se pueden suponerse créditos compartidos.

Las entradas SCT/RCT pueden escribirse mediante software. En un ejemplo, el software puede mantener un duplicado de la configuración de la conexión. Para actualizar una entrada SCT o RCT, el usuario puede escribir en el puerto register_wrdata_in, que puede estar vinculado a los registros en la soft shell o el entorno correspondiente a la lógica de la aplicación. La Tabla 6 siguiente es un ejemplo del formato de una estructura de datos que puede usarse para actualizar las entradas en la SCT o en la RCT.

Para escribir en una entrada de SCT, se puede establecer scte_not_rcte a 1, establecer el valor sCTI al valor del índice para el SCT en el que se está escribiendo y, a continuación, establecer los otros campos de la estructura de datos en la Tabla 6 de manera apropiada. Con respecto a la sincronización, el valor de register_write_in puede conmutarse a un valor alto durante al menos un ciclo. rCTI puede establecerse a la entrada RCT del componente de aceleración remoto (en este ejemplo, rCTI está incluido en los paquetes UDP enviados a ese componente de aceleración y así es como se busca la conexión correcta en el otro extremo). IPAddr puede establecerse a la dirección IP del componente de aceleración de destino. MacAddr puede establecerse a la dirección MAC de un servidor en el mismo segmento LAN que el componente de aceleración o a la dirección MAC del enrutador para los servidores remotos. VirtualChannel puede establecerse buscándolo en el flit que se recibe desde el enrutador 604 elástico. Para escribir en una entrada RCT, se puede establecer scte_not_rcte a 0, establecer el valor rCTI al valor del índice de la RCT en el que se está escribiendo y, a continuación, establecer los otros campos de la estructura de datos en la Tabla 6 de manera apropiada. rCTI puede establecerse a la entrada RCT del componente de aceleración de envío. IPAddr puede establecerse a la dirección IP del componente de aceleración de envío. MacAddr puede ignorarse para el propósito de escribir en la RCT. VirtualChannel puede establecerse al canal en el que se enviará el mensaje al enrutador 604 elástico.

Como ejemplo, para establecer un enlace unidireccional desde un nodo A (por ejemplo, el componente A de transporte (10.0.0.1)) al nodo B (por ejemplo, el componente B de transporte (10.0.0.2)), se podría: (1) en el componente A de transporte crear una SCTE {sCTI: 1, rCTI: 4, IP: 10.0.0.2, VC: 1, Mac: 01-02-03-04-05-06}; y (2) en el componente B de transporte, crear una RCTE {rCTI: 4, sCTI: 1, IP: 10.0.0.1, VC: 2}. En este ejemplo, esto requeriría mensajes recibidos desde un enrutador elástico en el componente A de transporte con DestIP == 10.0.0.2 y VC == 1 y enviar los mismos al componente B de transporte en un paquete. La cabecera del paquete tendrá el campo rCTI establecido a 4 (el valor rCTI leído desde la SCT). El componente B de transporte accederá a su entrada RCT 4 y sabrá que el mensaje debería emitirse en el VC 2. También generará un ACK a devolver al componente A de transporte. En este paquete, el campo sCTI tendrá el valor 1 (según el valor sCTI leído desde la RCT).

Una instancia LTL asociada con el componente 600 de transporte puede almacenar en memoria intermedia todos los paquetes enviados hasta que reciba un acuse de recibo (ACK) desde el componente de aceleración de recepción. Si no llega un ACK para una conexión en un período de tiempo de espera configurable, el paquete puede volver a transmitirse. En este ejemplo, se retransmitirán todos los paquetes sin acuse de recibo, empezando por el más antiguo. Es posible que la caída de un paquete que pertenece a una SCT determinada no altere el comportamiento de ninguna otra conexión, es decir, es posible que los paquetes para otras conexiones no se retransmitan. Debido a que la instancia LTL puede requerir un canal de comunicación fiable y los paquetes pueden perderse ocasionalmente en la red, en un ejemplo, puede usarse un mecanismo de reintento basado en un tiempo de espera.

Si un paquete no recibe un acuse de recibo en un cierto período de tiempo, puede volver a transmitirse. El período de tiempo de espera puede establecerse mediante un parámetro de configuración. Una vez transcurrido el tiempo de espera, el componente 600 de transporte puede ajustar la separación entre paquetes de congestión para ese flujo.

El componente 600 de transporte puede proporcionar también un control de congestión. Si una instancia LTL transmite datos a un receptor que no es capaz de absorber el tráfico a la velocidad completa de la línea, la funcionalidad de control de congestión puede permitirle reducir fácilmente la frecuencia de los paquetes que se envían al nodo de destino. Cada conexión LTL puede tener un estado de separación entre paquetes asociado que controla el número mínimo de ciclos entre la transmisión de paquetes en un flujo. En la creación de una nueva conexión, el IPG puede establecerse a 1, permitiendo de manera efectiva el uso completo de cualquier ancho de banda disponible. Si se llega al límite del tiempo de espera, se recibe una notificación ECN o NACK en un flujo, el retraso puede multiplicarse por el parámetro cfg.throttle_credit_multiple (véase la Tabla 3) o aumentarse según el parámetro cfg.throttle_credits_per_scrub (véase la Tabla 3; dependiendo de si se selecciona un retroceso lineal o exponencial). Cada ACK recibido puede reducir el IPG según el parámetro cfg.throttle_credits_per_scrub (véase la Tabla 3) o dividirlo por el parámetro cfg.throttle_credit_multiple (véase la Tabla 3; dependiendo de si se selecciona un retorno lineal o exponencial). Una instancia LTL puede no aumentar el IPG de un flujo más de una vez en cada período de tiempo predeterminado; por ejemplo, no más de cada 2 microsegundos (en este ejemplo, esto puede controlarse mediante el parámetro cfg.throttle_scrub_delay (véase la Tabla 3)).

De manera consistente con un ejemplo de LTL, el componente 600 de transporte puede intentar la retransmisión 128 veces. Si, después de 128 reintentos, todavía no se recibe acuse de recibo del paquete, el paquete puede descartarse y la memoria intermedia puede liberarse. A menos que el bit de configuración disable_timeouts esté activado, el componente 600 de transporte puede borrar también el SCTE para esta conexión para prevenir la transmisión de mensajes y paquetes adicionales. En este ejemplo, en este punto, no pueden intercambiarse datos entre los participantes en el enlace, ya que sus números de secuencia estarán desincronizados. Esta conexión debería reestablecerse.

Cuando una instancia LTL asociada con el componente 600 de transporte recibe de manera exitosa un paquete, generará un acuse de recibo (por ejemplo, un paquete de carga útil vacía con el bit de indicador ACK activado). Los acuses de recibo (ACKs) pueden incluir un número de secuencia que le indica al emisor el último paquete que se recibió de manera exitosa y la SCTI a la que el emisor debe acreditar el ACK (este valor puede almacenarse en la RCT del generador de ACK). Como ejemplo de LTL, pueden usarse las siguientes reglas para generar acuses de recibo: (1) si el número de secuencia RX coincide con el número de secuencia esperado (en RCT), se genera un ACK con el número de secuencia recibido; (2) si el número de secuencia RX es menor que el número de secuencia esperado, el paquete se descarta, pero se genera un ACK con el número de secuencia recibido más alto (esto puede cubrir el caso en el que un paquete se envía dos veces (quizás debido a un tiempo de espera), pero, a continuación, se recibe correctamente); y (3) si el número de secuencia RX es mayor que el número de secuencia esperado, el paquete se descarta y no se genera ningún ACK.

Una instancia de una LTL asociada con el componente 600 de transporte puede generar NACKs bajo ciertas condiciones. Estos pueden ser paquetes indicados con ambos bits indicadores ACK y NACK activados. Un NACK puede ser una solicitud para que el emisor retransmita un paquete particular y todos los paquetes posteriores.

En un ejemplo, bajo dos condiciones, el componente 600 de transporte puede requerir la generación de un NACK: (1) si un paquete se descarta debido a créditos de enrutador elástico insuficientes para aceptar el paquete completo, el componente 600 de transporte puede enviar un NACK una vez que haya suficientes créditos; o (2) si un paquete se descarta debido a que otro emisor retiene actualmente el bloqueo en un canal virtual de destino, el componente 600 de transporte puede enviar un NACK una vez que se libera el bloqueo VC.

Cuando un punto extremo LTL está recibiendo tráfico desde múltiples emisores, el receptor puede mantener una estructura de datos secundaria por cada VC (VCLockQueue) que puede realizar un seguimiento de qué emisores han perdido sus paquetes debido a se estaba recibiendo otro mensaje en un VC específico. Esta estructura de datos secundaria puede usarse para coordinar múltiples emisores mediante solicitudes de retransmisión (NACKs) explícitas.

En un ejemplo, una vez que una instancia LTL asociada con el componente 600 de transporte comienza a recibir un mensaje en un VC específico, ese VC se bloquea para ese único emisor hasta que se hayan recibido todos los paquetes de ese mensaje. Si otro emisor intenta enviar un paquete en el mismo VC mientras está bloqueado o mientras no hay suficientes créditos ER disponibles, el paquete se descartará y el receptor se colocará en la VCLockQueue. Una vez liberado el bloqueo o cuando hay suficientes créditos de ER, la instancia LTL extraerá un elemento de la VCLockQueue y enviará una solicitud de retransmisión (NACK) al siguiente emisor que se colocó en VCLockQueue. Después de ser extraído desde la VCLockQueue, puede darse a un emisor la prioridad más alta para los próximos 200.000 ciclos (~1,15ms). Los paquetes desde los otros emisores en el mismo VC se descartarán durante estos 200.000 ciclos. Esto puede garantizar que todos los emisores a los que se les han descartado paquetes finalmente tengan la oportunidad de enviar su mensaje.

Cuando un receptor descarta el paquete de un emisor debido a que otro emisor tiene el bloqueo de VC, el receptor puede colocar al emisor (cuyo paquete ha sido descartado) en la VCLockQueue y enviar un NACK que incluye también el indicador XOFF, indicando que el emisor no debería intentar retransmitir durante algún tiempo (que viene dado por el parámetro cfg.xoff_period). Si el receptor no tiene créditos ER, el NACK puede incluir también el indicador de congestión.

Cuando un emisor recibe un NACK con el indicador XOFF, puede retrasar el siguiente paquete un período de retroceso (por ejemplo, el xoff_period). Si el NACK no incluye el indicador de congestión (es decir, la pérdida no es debida a créditos insuficientes sino a un bloqueo VC), entonces el emisor puede anotar que el bloqueo VC está activo para ese flujo. Cuando un flujo tiene el bloqueo VC habilitado, los emisores pueden deben asegurarse de reducir la velocidad después de terminar cada mensaje, ya que saben que los paquetes de los mensajes posteriores serán descartados ya que compiten con otros emisores que recibirán a continuación el bloqueo VC. Sin embargo, en este ejemplo, los emisores deberán asegurarse de enviar el primer paquete de un mensaje posterior antes de reducir la velocidad (aunque saben que se descartará) para asegurarse de que se coloquen en la VCLockQueue.

La Fig. 7 muestra un diagrama 700 de flujo para un procedimiento para el procesamiento de mensajes usando componentes de transporte para proporcionar un servicio según un ejemplo. En un ejemplo, la lógica de aplicación (por ejemplo, la lógica 608 de aplicación de la Fig. 6) correspondiente al servicio, tal como un servicio de clasificación de resultados de una búsqueda, puede dividirse y mapearse en múltiples roles de los componentes de acelerador. Tal como se ha descrito anteriormente, la lógica de aplicación puede conceptualizarse como que incluye un dominio de aplicación (por ejemplo, un "rol"). El dominio o rol de aplicación puede representar una parte de la funcionalidad incluida en un servicio compuesto distribuido sobre múltiples componentes de aceleración. Los roles en cada componente de aceleración en un grupo de componentes de aceleración pueden vincularse entre sí para crear un grupo que proporcione la aceleración de servicio para el dominio de la aplicación. Cada dominio de aplicación puede alojar una lógica de aplicación para realizar las tareas específicas del servicio (tales como una parte de la funcionalidad para clasificar documentos, encriptar datos, comprimir datos, facilitar la visión por ordenador, facilitar traducción de voz, el aprendizaje automático, etc.). La etapa 702 puede incluir la recepción de un mensaje desde un servidor para realizar una tarea correspondiente a un servicio. La etapa 704 puede incluir reenviar el mensaje a un componente de aceleración en la cabeza de una canalización multietapa de componentes de aceleración, donde los componentes de aceleración pueden estar asociados con un primer conmutador. De esta manera, cuando una solicitud para una función asociada con un servicio, por ejemplo, llega una solicitud de clasificación desde un servidor en la forma de un mensaje PCI rápido, puede ser enviada a la cabeza de una canalización multietapa de componentes de aceleración. En la etapa 706, el componente de aceleración que ha recibido el mensaje puede determinar si el mensaje es o no para el componente de aceleración en la cabeza. Si el mensaje es para el componente de aceleración en la cabeza de una etapa de canalización, entonces el componente de aceleración en la cabeza de la etapa de tubería puede procesar el mensaje en el componente de aceleración. Como parte de esta etapa, un enrutador elástico (por ejemplo, el enrutador 604 elástico de la Fig. 6) puede reenviar el mensaje directamente al rol. En un ejemplo, el formato de paquete LTL (por ejemplo, tal como se muestra en la Tabla 6) puede incluir un indicador de difusión (por ejemplo, el bit 3 bajo la cabecera de indicadores, tal como se muestra en la Tabla 6) y un indicador de retransmisión (por ejemplo, el bit 2 bajo la cabecera de indicadores, tal como se muestra en la Tabla 6). El indicador de difusión puede indicar a un componente de aceleración que el mensaje está destinado a múltiples componentes de aceleración. El indicador de retransmisión puede indicar a un componente de aceleración que se solicita la retransmisión del mensaje. En ambos casos, el formato de paquete LTL puede incluir cabeceras que enumeran las direcciones IP para el destino o los destinos específicos. De esta manera, cuando un componente de aceleración recibe un mensaje con el indicador de difusión activado, en la etapa 712, el componente de aceleración (por ejemplo, usando el componente 600 de transporte) puede transmitir el mensaje como un mensaje punto-a-punto a un conjunto seleccionado de componentes de aceleración, en el que cada uno de los mismos está asociado con un conmutador de tipo parte superior del bastidor (TOR) diferente. En un ejemplo, el mensaje punto-a-punto se transmite usando una funcionalidad de la capa 3. En este ejemplo, cuando el componente 600 de transmisión recibe un paquete (por ejemplo, una parte del mensaje punto-a-punto) con el indicador de difusión activado, puede procesar la lista de destinos; si contiene otras direcciones además de su propia dirección IP, añadirá el paquete a sus propias memorias intermedias de transmisión, configurará un campo de bits para realizar un seguimiento de la recepción por cada uno de los destinos y, a continuación, empezará a transmitir a cada receptor uno por uno (sin los campos difusión o retransmitir). Los componentes de aceleración de destino pueden acusar recibo (usando ACK) de cada paquete tras una recepción exitosa y el emisor marcará el bit apropiado en el campo de bits. Una vez que todos los destinos acusan recibo de un paquete, la memoria intermedia de envío puede liberarse. 17

A continuación, en la etapa 714, cada uno de entre el conjunto de componentes de aceleración puede transmitir, usando la funcionalidad de la capa de enlace de datos, ese mensaje a cualquier otro componente de aceleración asociado con el conmutador TOR respectivo. Un ejemplo de funcionalidad de la capa de enlace de datos pueden ser los paquetes de difusión Ethernet de la capa 2. En un ejemplo, cuando el componente 600 de transporte recibe un paquete (por ejemplo, una parte del mensaje punto-a-punto) con el indicador de difusión activado, puede procesar la lista de destinos; si contiene otras direcciones además de su propia dirección IP, añadirá el paquete a sus propias memorias intermedias de transmisión, configurará un campo de bits para realizar un seguimiento de la recepción por cada uno de los destinos y, a continuación, enviar una difusión Ethernet de capa 2 (con el indicador de difusión y la lista de destinos) a todos los componentes de aceleración que comparten un conmutador TOR común. Los componentes de aceleración de destino pueden acusar recibo (usando ACK) de cada paquete tras una recepción exitosa y el emisor marcará el bit apropiado en el campo de bits. Una vez que todos los destinos acusan recibo de un paquete, la memoria intermedia de envío puede liberarse. Aunque la Fig. 7 muestra un cierto número de etapas enumeradas en un orden determinado, podría haber menos o más etapas y dichas etapas podrían realizarse en un orden diferente.

Los componentes de aceleración pueden agruparse entre sí como parte de un gráfico. No es necesario que los componentes de aceleración agrupados estén físicamente próximos unos a otros; por el contrario, podrían asociarse con diferentes partes del centro de datos y aun así estar agrupados vinculando los mismos como parte de un plano de aceleración. En un ejemplo, el gráfico puede tener una determinada topología de red dependiendo de cuál de los componentes de aceleración asociados con cuál de los conmutadores TOR están acoplados para acelerar un servicio. La topología de red puede crearse de manera dinámica en base a la información de configuración recibida desde un administrador de servicios para el servicio. El administrador de servicios puede ser un software de nivel superior asociado con el servicio. En un ejemplo, la topología de red puede ajustarse de manera dinámica en base al menos a una métrica de rendimiento asociada con la red (por ejemplo, la red 120) que interconecta el plano de aceleración y un plano de software que incluye componentes de servidor configurados para ejecutar instrucciones correspondientes al por lo menos un servicio. El administrador de servicios puede usar un servicio de telemetría para supervisar el rendimiento de la red. La métrica de rendimiento de la red puede seleccionarse sustancialmente en tiempo real en base al menos a los requisitos del al menos un servicio. La al menos una métrica de rendimiento de la red puede comprender la latencia, el ancho de banda o cualquier otra métrica de rendimiento especificada por un administrador de servicios o lógica de aplicación correspondiente al por lo menos un servicio.

En un ejemplo, los componentes de aceleración pueden difundir mensajes usando un proceso de transmisión basado en árbol que incluye enlaces punto-a-punto para los componentes de aceleración conectados a través de difusiones Ethernet de capa 3 y capa 2 para los componentes de aceleración que comparten un conmutador TOR. El árbol puede ser de dos niveles o puede tener más niveles dependiendo de las limitaciones de ancho de banda impuestas por la red que interconecta los componentes de aceleración.

La Fig. 8 muestra un diagrama de flujo para un procedimiento de transmisión de mensajes según un ejemplo. En la etapa 802, un primer componente de aceleración, asociado con un primer conmutador TOR, puede recibir un mensaje desde un servidor. Tal como se ha descrito anteriormente, un componente de aceleración puede incluir un componente de transporte para gestionar la mensajería (por ejemplo, el componente 430 de transporte de la Fig. 4, que se describe adicionalmente con respecto al componente 600 de transporte de la Fig. 6). En la etapa 804, usando una funcionalidad de capa de red (por ejemplo, la funcionalidad de la capa 3), el primer componente de aceleración puede transmitir el mensaje a un segundo componente de aceleración asociado con un segundo conmutador TOR, diferente del primer conmutador TOR. En la etapa 806, usando una funcionalidad de capa de red (por ejemplo, la funcionalidad de la capa 3), el primer componente de aceleración puede transmitir el mensaje a un tercer componente de aceleración asociado con un tercer conmutador TOR, diferente del primer conmutador TOR y del segundo conmutador TOR. En este ejemplo, cuando el componente 600 de transmisión recibe un paquete (por ejemplo, una parte del mensaje recibido) con el indicador de difusión activado, puede procesar la lista de destinos; si contiene otras direcciones además de su propia dirección IP, añadirá el paquete a sus propias memorias intermedias de transmisión, configurará un campo de bits para realizar un seguimiento de la recepción por cada uno de los destinos y, a continuación, empezará a transmitir a cada receptor uno por uno (sin los campos difusión o retransmitir). Los componentes de aceleración de destino pueden acusar recibo (usando ACK) de cada paquete tras una recepción exitosa y el emisor marcará el bit apropiado en el campo de bits. Una vez que todos los destinos acusan recibo de un paquete, la memoria intermedia de envío puede liberarse.

En la etapa 810, el segundo componente de aceleración, usando una funcionalidad de capa de enlace de datos (por ejemplo, la funcionalidad de difusión Ethernet de la capa 2), puede difundir el mensaje a los otros componentes de aceleración asociados con el segundo conmutador TOR. En este ejemplo, cuando el componente 600 de transporte recibe un paquete (por ejemplo, una parte del mensaje punto-a-punto) con el indicador de difusión activado, puede procesar la lista de destinos; si contiene otras direcciones además de su propia dirección IP, añadirá el paquete a sus propias memorias intermedias de transmisión, configurará un campo de bits para realizar una supervisión de la recepción de cada uno de los destinos y, a continuación, enviará una transmisión Ethernet de la capa 2 (con el indicador de difusión y la lista de destinos) a todos los componentes de aceleración que comparten un conmutador TOR común. Los componentes de aceleración de destino pueden acusar recibo (usando ACK) de cada paquete una vez recibido exitosamente y el emisor marcará el bit apropiado en el campo de bits. Una vez que todos los destinos han acusado recibo de un paquete, la memoria intermedia de envío puede liberarse.

En la etapa 810, el tercer componente de aceleración, usando una funcionalidad de capa de enlace de datos (por ejemplo, la funcionalidad de difusión de Ethernet de la capa 2), puede difundir el mensaje a los otros componentes de aceleración asociados con el tercer conmutador TOR. En este ejemplo, cuando el componente 600 de transporte recibe un paquete (por ejemplo, una parte del mensaje punto-a-punto) con el indicador de difusión activado, puede procesar la lista de destinos; si contiene otras direcciones además de su propia dirección IP, añadirá el paquete a sus propias memorias intermedias de transmisión, configurará un campo de bits para realizar un seguimiento de la recepción de cada uno de los destinos y, a continuación, enviará una difusión Ethernet de capa 2 (con el indicador de difusión y la lista de destinos) a todos los componentes de aceleración que comparten un conmutador TOR común. Los componentes de aceleración de destino pueden acusar recibo (usando ACK) de cada paquete tras una recepción exitosa y el emisor marcará el bit apropiado en el campo de bits. Una vez que todos los destinos acusan recibo de un paquete, la memoria intermedia de envío puede liberarse. Aunque la Fig. 8 muestra un cierto número de etapas enumeradas en un orden determinado, podría haber menos o más etapas y dichas etapas podrían realizarse en un orden diferente.

Como conclusión, se proporciona un sistema que comprende un plano de software que incluye múltiples componentes de servidor configurados para ejecutar instrucciones correspondientes a al menos un servicio y un plano de aceleración que incluye múltiples componentes de aceleración configurables para acelerar el al menos un servicio. El sistema puede incluir además una red configurada para interconectar el plano de software y el plano de aceleración, la red puede incluir un primer conmutador de tipo parte superior del bastidor (TOR) asociado con un primer subconjunto de entre los múltiples componentes de aceleración, un segundo conmutador TOR asociado con un segundo subconjunto de los múltiples componentes de aceleración, y un tercer conmutador TOR asociado con un tercer subconjunto de entre los múltiples componentes de aceleración, donde cualquiera de entre el primer subconjunto de los múltiples componentes de aceleración es configurable para transmitir un mensaje punto-a-punto a cualquiera de entre el segundo subconjunto de los múltiples componentes de aceleración y para transmitir el mensaje punto-a-punto a cualquiera de entre el tercer subconjunto de los múltiples componentes de aceleración, y donde cualquiera de entre el segundo subconjunto de los múltiples componentes de aceleración es configurable para difundir el mensaje punto-a-punto a la totalidad del segundo subconjunto de los múltiples componentes de aceleración, y donde cualquiera de entre el tercer subconjunto de los múltiples componentes de aceleración es configurable para transmitir el mensaje punto-a-punto a la totalidad del tercer subconjunto de los múltiples componentes de aceleración. El mensaje punto-a-punto puede transmitirse usando una funcionalidad de la capa 3. El mensaje punto-a-punto puede difundirse usando una funcionalidad de difusión Ethernet de la capa 2. El mensaje punto-a-punto puede difundirse sin depender de ningún soporte de difusión desde las capas más altas de la red que una capa 2 de la red o cualquier soporte de multidifusión desde las capas más altas de la red que la capa 2 de la red. Cualquiera de entre el primer subconjunto de los múltiples componentes de aceleración puede configurarse para crear de manera dinámica una topología de red que comprende cualquiera de entre el segundo subconjunto de los múltiples componentes de aceleración y el tercer subconjunto de los múltiples componentes de aceleración. Cualquiera de entre el primer subconjunto de los múltiples componentes de aceleración puede configurarse además para ajustar de manera dinámica la topología de la red en base a la al menos una métrica de rendimiento asociada con la red configurada para interconectar el plano de software y el plano de aceleración. La al menos una métrica de rendimiento de la red puede seleccionarse sustancialmente en tiempo real por cualquiera de entre el primer subconjunto de los múltiples componentes de aceleración en base al menos en los requisitos del al menos un servicio. La al menos una métrica de rendimiento de red puede comprender la latencia, el ancho de banda o cualquier otra métrica de rendimiento especificada por una lógica de aplicación correspondiente al por lo menos un servicio.

En otro ejemplo, la presente descripción se refiere a un procedimiento para permitir que un primer componente de aceleración de entre una primera pluralidad de componentes de aceleración, asociada con un primer conmutador de tipo parte superior del bastidor (TOR), transmita mensajes a otros componentes de aceleración en un plano de aceleración configurable para proporcionar una aceleración de servicio para al menos un servicio. El procedimiento puede incluir la transmisión por parte de un primer componente de aceleración de un mensaje punto-a-punto a un segundo componente de aceleración, asociado con un segundo conmutador TOR diferente del primer conmutador TOR, y a un tercer componente de aceleración, asociado a un tercer conmutador TOR diferente del primer conmutador TOR y el segundo conmutador TOR. El procedimiento puede incluir además la difusión por parte del segundo componente de aceleración del mensaje punto-a-punto a la totalidad de una segunda pluralidad de componentes de aceleración asociados con el segundo conmutador TOR. El procedimiento puede incluir además la difusión por parte del tercer componente de aceleración del mensaje punto-a-punto a la totalidad de una tercera pluralidad de componentes de aceleración asociados con el tercer conmutador TOR. El primer componente de aceleración puede transmitir el mensaje punto-a-punto usando una funcionalidad de la capa 3. Cada uno de entre el segundo componente de aceleración y el tercer componente de aceleración pueden difundir el mensaje punto-a­ punto usando una funcionalidad de difusión Ethernet de capa 2. El procedimiento puede incluir además ajustar de manera dinámica la topología de la red en base a al menos una métrica de rendimiento asociada con una red que interconecta el plano de aceleración y un plano de software que incluye múltiples componentes de servidor configurados para ejecutar instrucciones correspondientes al por lo menos un servicio. La al menos una métrica de rendimiento de red puede seleccionarse sustancialmente en tiempo real por cualquiera del primer subconjunto de los múltiples componentes de aceleración en base al menos en los requisitos del al menos un servicio. La al menos una métrica de rendimiento de red puede comprender la latencia, el ancho de banda o cualquier otra métrica de rendimiento especificada por una lógica de aplicación correspondiente al por lo menos un servicio.

En todavía otro ejemplo, la presente descripción se refiere a un componente de aceleración para su uso de entre una primera pluralidad de componentes de aceleración, asociado con un primer conmutador de tipo parte superior del bastidor (TOR), para transmitir mensajes a otros componentes de aceleración en un plano de aceleración configurable para proporcionar aceleración de servicio para al menos un servicio. El componente de aceleración puede incluir un componente de transporte configurado para transmitir un primer mensaje punto-a-punto a un segundo componente de aceleración, asociado a un segundo conmutador TOR diferente del primer conmutador TOR, y a un tercer componente de aceleración, asociado con un tercer conmutador TOR diferente del primer conmutador TOR y del segundo conmutador TOR. El componente de transporte puede configurarse además para difundir un segundo mensaje punto-a-punto a la totalidad de una segunda pluralidad de componentes de aceleración asociados con el segundo conmutador TOR y a la totalidad de una tercera pluralidad de componentes de aceleración asociados con el tercer conmutador TOR. El mensaje punto-a-punto puede transmitirse usando una funcionalidad de la capa 3. El mensaje punto-a-punto puede difundirse usando una funcionalidad de difusión Ethernet de la capa 2. El componente de aceleración puede configurarse además para difundir el segundo mensaje punto-a-punto en una red que interconecta los componentes de aceleración en el plano de aceleración sin depender de ningún soporte para la difusión o la multidifusión desde capas de red superiores a la capa 2 de la red.

Debe entenderse que los sistemas, los procedimientos, los módulos y los componentes representados en la presente memoria son meramente ejemplares. De manera alternativa o adicional, la funcionalidad descrita en la presente memoria puede realizarse, al menos en parte, mediante uno o más componentes lógicos de hardware. Por ejemplo, y sin limitación, los tipos de componentes lógicos de hardware ilustrativos que pueden usarse incluyen matrices de puertas programables por campo (FPGA), circuitos integrados específicos de aplicación (ASIC), productos estándar de aplicación específica (ASSP), sistemas de tipo sistema en chip (SOC), dispositivos lógicos programables complejos (CPLD), etc. En un sentido abstracto, pero aun así definido, cualquier disposición de componentes para conseguir la misma funcionalidad se "asocia" de manera efectiva de manera que se consiga la funcionalidad deseada. Por lo tanto, dos componentes cualesquiera en la presente memoria combinados para conseguir una funcionalidad particular pueden considerarse como "asociados" entre sí de manera que se consiga la funcionalidad deseada, independientemente de las arquitecturas o de los componentes intermedios. Asimismo, dos componentes cualesquiera asociados de esta manera pueden considerarse también como "conectados operativamente" o "acoplados" entre sí para conseguir la funcionalidad deseada.

La funcionalidad asociada con algunos ejemplos descritos en la presente descripción puede incluir también instrucciones almacenadas en un medio no transitorio. La expresión "medio no transitorio", tal como se usa en la presente memoria, se refiere a cualquier medio que almacena datos y/o instrucciones que causan que una máquina funcione de una manera específica. Los medios no transitorios ejemplares incluyen medios no volátiles y/o medios volátiles. Los medios no volátiles incluyen, por ejemplo, un disco duro, una unidad de estado sólido, un disco o cinta magnética, un disco o cinta óptica, una memoria flash, una EPROM, NVRAM, PRAM u otros medios similares, o versiones en red de dichos medios. Los medios volátiles incluyen, por ejemplo, memoria dinámica como DRAM, SRAM, una caché u otros medios similares. Los medios no transitorios son distintos de los medios de transmisión, pero pueden usarse junto con los mismos. Los medios de transmisión se usan para transferir datos y/o instrucciones a o desde una máquina. Los medios de transmisión ejemplares incluyen cables coaxiales, cables de fibra óptica, cables de cobre y medios inalámbricos, tales como ondas de radio.

Además, las personas expertas en la técnica reconocerán que los límites entre la funcionalidad de las operaciones descritas anteriormente son meramente ilustrativos. La funcionalidad de múltiples operaciones puede combinarse en una única operación y/o la funcionalidad de una única operación puede distribuirse en operaciones adicionales. Además, las realizaciones alternativas pueden incluir múltiples instancias de una operación particular, y el orden de las operaciones puede alterarse en diversas realizaciones diferentes.

Aunque la descripción proporciona ejemplos específicos, pueden realizarse diversas modificaciones y cambios sin apartarse del alcance de la descripción tal como se establece en las reivindicaciones siguientes. Por consiguiente, la memoria descriptiva y las figuras deben considerarse en un sentido ilustrativo en lugar de en un sentido restrictivo, y se pretende que la totalidad de dichas modificaciones estén incluidas dentro del alcance de la presente descripción. Ningún beneficio, ventaja o solución a los problemas que se describen en la presente memoria con relación a un ejemplo específico debería interpretarse como una característica o elemento crítico, requerido o esencial de cualquiera o de todas las reivindicaciones.

Además, los términos "un" o "una", tal como se usan en la presente memoria, se definen como uno o más de uno. Además, el uso de frases introductorias, tales como "al menos uno" y "uno o más", en las reivindicaciones no debe interpretarse como que implica que la introducción de otro elemento de reivindicación con los artículos indefinidos "un" o "una" limita cualquier reivindicación que contiene dicho elemento de reivindicación introducido a invenciones que contienen solo uno de dichos elementos, incluso cuando la misma reivindicación incluya las frases introductorias "uno o más" o "al menos uno" y artículos indefinidos tales como "un" o "una". Lo mismo se aplica al uso de artículos definidos.

A menos que se indique lo contrario, los términos tales como "primero" y "segundo" se usan para distinguir de manera arbitraria entre los elementos que describen dichos términos. De esta manera, estos términos no pretenden indicar necesariamente una priorización temporal o de otro tipo de dichos elementos.

Claims (15)

REIVINDICACIONES

1. Sistema que comprende:

un plano (104) de software que incluye múltiples componentes (108) de servidor configurados para ejecutar instrucciones correspondientes a al menos un servicio;

un plano (106) de aceleración que incluye múltiples componentes (110, 116) de aceleración configurables para acelerar el al menos un servicio; y

una red (120) configurada para interconectar el plano (104) de software y el plano (106) de aceleración, comprendiendo la red (104) un primer conmutador (302) de tipo parte superior del bastidor, TOR, asociado con un primer subconjunto de los múltiples componentes de aceleración, un segundo conmutador (304) TOR asociado con un segundo subconjunto de los múltiples componentes de aceleración, y un tercer conmutador (306) TOR asociado con un tercer subconjunto de los múltiples componentes de aceleración, en el que cualquiera de entre el primer subconjunto de los múltiples componentes de aceleración es configurable para transmitir un mensaje punto-a-punto a cualquiera de entre el segundo subconjunto de los múltiples componentes de aceleración; y en el que cualquiera de entre el primer subconjunto de los múltiples componentes de aceleración está caracterizado por ser configurable para transmitir el mensaje punto-a-punto a cualquiera de entre el tercer subconjunto de los múltiples componentes de aceleración, y en el que cualquiera de entre el segundo subconjunto de los múltiples componentes de aceleración es configurable para difundir el mensaje punto-a-punto a la totalidad del segundo subconjunto de los múltiples componentes de aceleración, y en el que cualquiera de entre el tercer subconjunto de los múltiples componentes de aceleración es configurable para difundir el mensaje punto-a-punto a la totalidad del tercer subconjunto de los múltiples componentes de aceleración.

2. Sistema según la reivindicación 1, en el que el mensaje punto-a-punto se transmite usando una funcionalidad de la capa 3.

3. Sistema según la reivindicación 1, en el que el mensaje punto-a-punto se transmite usando una funcionalidad de difusión Ethernet de la capa 2.

4. Sistema según la reivindicación 1, en el que cualquiera de entre el primer subconjunto de los múltiples componentes de aceleración está configurado para crear de manera dinámica una topología de red que comprende cualquiera de entre el segundo subconjunto de los múltiples componentes de aceleración y el tercer subconjunto de los múltiples componentes de aceleración.

5. Sistema según la reivindicación 4, en el que cualquiera de entre el primer subconjunto de los múltiples componentes de aceleración está configurado además para ajustar de manera dinámica la topología de red en base a al menos una métrica de rendimiento asociada con la red configurada para interconectar el plano de software y el plano de aceleración.

6. Sistema según la reivindicación 5, en el que la al menos una métrica de rendimiento de red es seleccionada sustancialmente en tiempo real por cualquiera de entre el primer subconjunto de los múltiples componentes de aceleración en base al menos a los requisitos del al menos un servicio.

7. Sistema según la reivindicación 6, en el que la al menos una métrica de rendimiento de red comprende la latencia, el ancho de banda o cualquier otra métrica de rendimiento especificada por una lógica de aplicación correspondiente al por lo menos un servicio.

8. Sistema según la reivindicación 1, en el que el mensaje punto-a-punto se difunde sin depender de ningún soporte de difusión desde capas de red superiores a una capa 2 de red o ningún soporte de multidifusión de capas de red superiores a la capa 2 de red.

9. Procedimiento para permitir que un primer componente de aceleración de entre una primera pluralidad de componentes (110, 116) de aceleración, asociados con un primer conmutador (302) de tipo parte superior del bastidor, TOR, transmita mensajes a otros componentes (110, 116) de aceleración en un plano (106) de aceleración configurable para proporcionar aceleración de servicio para al menos un servicio, comprendiendo el procedimiento:

la transmisión por parte del primer componente de aceleración de un mensaje punto-a-punto a un segundo componente de aceleración, asociado con un segundo conmutador TOR diferente del primer conmutador TOR, estando caracterizado el procedimiento por que el primer componente de aceleración transmite también el mensaje punto-a-punto a un tercer componente de aceleración, asociado con un tercer conmutador TOR diferente del primer conmutador TOR y del segundo conmutador TOR;

la difusión por parte del segundo componente de aceleración del mensaje punto-a-punto a la totalidad de una segunda pluralidad de componentes de aceleración asociados con el segundo conmutador TOR; y

la difusión por parte del tercer componente de aceleración del mensaje punto-a-punto a la totalidad de una tercera pluralidad de componentes de aceleración asociados con el tercer conmutador TOR.

10. Procedimiento según la reivindicación 9, que comprende además el primer componente de aceleración que transmite el mensaje punto-a-punto usando una funcionalidad de la capa 3.

11.Procedimiento según la reivindicación 9, que comprende además la difusión por parte de cada uno de entre el segundo componente de aceleración y el tercer componente de aceleración del mensaje punto-a-punto usando una funcionalidad de difusión Ethernet de la capa 2.

12. Procedimiento según la reivindicación 11, que comprende además crear de manera dinámica una topología de red que comprende cualquiera de los otros componentes de aceleración que incluyen la segunda pluralidad de componentes de aceleración y la tercera pluralidad de componentes de aceleración.

13. Procedimiento según la reivindicación 12, que comprende además ajustar de manera dinámica la topología de red en base a al menos una métrica de rendimiento asociada con una red que interconecta el plano de aceleración y un plano de software que incluye múltiples componentes de servidor configurados para ejecutar instrucciones correspondientes al por lo menos un servicio.

14. Procedimiento según la reivindicación 13, en el que la al menos una métrica de rendimiento de red se selecciona sustancialmente en tiempo real en base a al menos los requisitos del al menos un servicio.

15. Procedimiento según la reivindicación 14, en el que la al menos una métrica de rendimiento de red comprende la latencia, el ancho de banda o cualquier otra métrica de rendimiento especificada por una lógica de aplicación correspondiente al por lo menos un servicio.