Una crítica de GENEVE (un protocolo de encapsulación de red) es que utiliza campos de longitud de etiqueta valor, y estos son difíciles de procesar en hardware.
¿Por qué se considera esto poco amigable para el hardware? ¿Qué enfoques serían más amigables para la implementación de hardware de alta velocidad, y por qué?
La longitud del valor (TLV, por sus siglas en inglés) es un método para contener diferentes tipos de información de longitud variable en una estructura de datos.
Solo necesitas eso cuando no hay un subconjunto común de información que cada instancia de esa estructura de datos deba tener, o cuando el orden de los campos debe ser variable por alguna razón.
Piénsalo de esta manera: si todos los paquetes GENEVE tuvieran un campo "destino" que contuviera, digamos, una dirección de red de 64 bits, ¿por qué no definir simplemente que cada paquete comience con 64 bits de dirección de destino, y así te ahorras un tag y un campo de longitud?
El hardware (¡y eso incluye al hardware que ejecuta software!) es bueno para buscar valores en posiciones específicas. Por lo tanto, analizar un encabezado donde la dirección de destino siempre está en la posición x y siempre tiene una longitud y es muy fácil; solo lees la dirección de memoria x e interpretas el resultado como un entero de longitud y. Eso es lo que hacen, por ejemplo, las CPUs para cada cosa que leen de la RAM.
Por otro lado, si para entender un paquete necesitas buscar campos específicos yendo a través de campos TLV (bueno, el primer campo dice que no es el tag que estoy buscando, tiene longitud 14, así que salta 14 bits, aha, no es el field que busco, salta adelante, ...) entonces analizar ese paquete será lento. Eso es válido tanto para implementaciones de software como de hardware.
Incluso peor que lento, será no determinístico en complejidad. Por lo tanto, algunas estructuras TLV pueden tardar solo un ciclo de reloj en analizarse, otras necesitan iterar a través de 42 campos para hacer lo mismo. Si estás implementando una aplicación de procesamiento de señales, tener en cuenta retrasos aleatorios en uno de los pasos rápidamente se convierte en una pesadilla, ya que de repente necesitarás almacenar entradas, o aplicar contrapresión, o descartar datos, simplemente porque alguien decidió tener una estructura de datos flexible.
En software, a menudo es económico y relativamente rápido preasignar una estructura de encabezado con compensaciones fijas y "llenar" estos campos a medida que iteras a través de la estructura TLV entrante. Pero: para eso, necesitas RAM, y a menudo bastante RAM, si no puedes saber qué campos estás buscando en el momento en que comienzas a analizar la estructura.
Por lo tanto, TLV es un esquema común para la serialización de datos débilmente estructurados para almacenamiento permanente o transmisión lenta. Generalmente es bastante indeseable para aplicaciones de transmisión, donde el mismo tipo de datos aparece con bastante frecuencia (por ejemplo, paquetes de red, cuadros de video, comandos de operación de infraestructura ...); en ese caso, preferirías definir estructuras fijas, incluso si eso desperdicia un poco de ancho de banda de transporte para campos ocasionalmente no utilizados.
Por ejemplo, la mayoría de los sistemas no utilizan todos los campos que puede tener un paquete Ethernet. Aún así, no intentarías ahorrar dos bytes: transportar 1490 o 1492 bytes en Ethernet Gigabit no hace mucha diferencia, pero tener que verificar en cada paquete si tu paquete es de tipo A o tipo B sí tiene un impacto negativo.
@Janka plantea un punto importante: Supongamos que el trabajo de todo tu hardware es simplemente copiar todo el paquete de entrada a salida. Ahora, genial, en lugar de decirle a tu motor DMA que copie un paquete de datos de entrada a salida, estás analizando todo lo de entrada para averiguar cuál es la longitud de tus datos. Eso es mucho, mucho más lento que simplemente copiar datos.
+1, pero la respuesta muy breve es: DMA no va a analizar los datos, por lo que los campos de longitud no hacen más que agregar sobrecarga.
Bueno, @Janka, sí, esa es la forma abreviada de "donde otros pueden simplemente elegir una posición fija y longitud de datos, el usuario de TLV tiene que analizar la estructura completa primero".
Esto es completamente cierto, pero en comparación con casi cualquier otro patrón que permita datos de longitud variable u opcionales, TLV es eficiente, fácil de procesar y permite futuras extensiones. En una escala que va desde los encabezados de Ethernet hasta SQL y "fecha en una calcomanía de renovación en una placa de matrícula capturada en un video de vigilancia", TLV se encuentra mucho más cerca del extremo más eficiente/amigable para las máquinas de la transmisión de datos.
Además de la excelente respuesta de Marcus, solo añadiría que los campos con longitud prefijada a menudo se consideran inferiores a los campos terminados porque requieren un contador adicional para procesarlos.
El ejemplo clásico son las cadenas de C. Solo se requiere un único puntero para procesar una cadena porque simplemente sigues incrementando el puntero hasta que llegas al carácter de terminación nulo. Con un prefijo de longitud, necesitas un contador adicional para rastrear cuántos caracteres has procesado, lo que significa más memoria y más sobrecarga de procesamiento para seguir incrementándolo.
Puede parecer una cosa pequeña, pero en sistemas muy poco potentes o de bajo coste o especificaciones bajas, importa.
Por otro lado, el código que procesa cadenas C a menudo necesita escanear la cadena una vez para encontrar la longitud, luego otra vez para procesarla. Ganar algo, perder algo.
I-Ciencias es una comunidad de estudiantes y amantes de la ciencia en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.
