Una crítica a GENEVE (un protocolo de encapsulación de red) es que utiliza campos de valor de longitud de etiqueta, y estos son difíciles de procesar en hardware.
¿Por qué esto se considera hostil al hardware? ¿Qué enfoques serían más amigables para la implementación de hardware de alta velocidad y por qué?
Etiqueta (o tipo) -length-value (TLV) es un método que contiene diferentes tipos de información de longitud variable en una estructura de datos.
Solo necesita que cuando no haya un subconjunto común de información que deba tener cada instancia de esa estructura de datos, o cuando el orden de los campos deba sea variable por alguna razón.
Piénselo de esta manera: si todos los paquetes GENEVE tuvieran un campo de "destino" que contuviera una dirección de red de 64 bits, ¿por qué no simplemente define que cada paquete comienza con 64 bits de la dirección de destino y se guarda una etiqueta y un campo de longitud? ?
¡El hardware (y eso incluye el hardware que ejecuta el software!) es bueno para buscar valores en posiciones específicas. Entonces, analizar un encabezado donde la dirección de destino siempre está en la posición x y siempre tiene la longitud y es muy fácil; acaba de leer la dirección de memoria x e interpreta el resultado como un número entero de longitud y. Eso es lo que p. Las CPU hacen por cada cosa que leen de la memoria RAM.
Si, por otro lado, para entender un paquete, primero debe buscar para campos específicos pasando por los campos TLV (ok, el primer campo dice que no es la etiqueta que estoy buscando , tiene una longitud de 14, así que avanza 14 bits, aha, no es el campo que estoy buscando, salta adelante, ...) luego el análisis de ese paquete será lento. Eso cuenta tanto para el software como para las implementaciones de hardware.
Incluso peor que lento, será no determinista en complejidad. Por lo tanto, algunas estructuras de TLV pueden tomar solo un ciclo de reloj para analizar, otras necesitan recorrer 42 campos para hacer lo mismo. Si está implementando una aplicación de procesamiento de señales, la contabilidad de los retrasos aleatorios en uno de los pasos se convierte rápidamente en una pesadilla, ya que de repente necesita amortiguar la entrada, aplicar la contrapresión o eliminar datos, simplemente porque alguien decidió tener una estructura de datos flexible. .
En el software, a menudo es barato y relativamente rápido simplemente preasignar una estructura de encabezado con compensaciones fijas y "completar" estos campos a medida que recorre la estructura del TLV entrante. Pero: para eso, necesita RAM, y con frecuencia bastante RAM, si no puede saber qué campos está buscando en el momento en que comienza a analizar la estructura.
Entonces, el TLV es un esquema común para la serialización de datos débilmente estructurados para un almacenamiento permanente o una transmisión lenta. Por lo general, es bastante indeseable para las aplicaciones de transmisión, donde el mismo tipo de datos se obtiene con bastante frecuencia (por ejemplo, paquetes de red, cuadros de video, comandos de operación de infraestructura ...); en ese caso, prefieres predefinir las estructuras fijas, incluso si se desperdicia un poco de ancho de banda de transporte para los campos no utilizados ocasionalmente.
Por ejemplo, la mayoría de los sistemas no usan todos los campos que puede tener un paquete Ethernet. Aún no intentará guardar dos bytes: el transporte de 1490 o 1492 bytes en Gigabit ethernet no hace mucha diferencia, pero tener que verificar si cada paquete es de tipo A o tipo B tiene un impacto negativo.
@Janka plantea un punto importante: suponga que todo el trabajo de su hardware es simplemente copiar todo el paquete de entrada a salida. Ahora, genial, en lugar de decirle a su motor de DMA que copie un paquete de datos de entrada a salida, está analizando todas las entradas para averiguar cuánto tiempo duran sus datos. Eso es mucho más lento que solo copiar datos.
Además de la gran respuesta de Marcus, simplemente agregué que los campos prefijados de longitud a menudo se consideran inferiores a los campos terminados porque requieren un contador adicional para procesarse.
El ejemplo clásico es C cadenas. Solo se requiere un solo puntero para procesar una cadena porque simplemente continúa incrementando el puntero hasta que alcanza el carácter de terminación nula. Con un prefijo de longitud, necesita un contador adicional para rastrear cuántos caracteres ha procesado, lo que significa más memoria y más sobrecarga de procesamiento para seguir incrementándola.
Puede parecer algo pequeño, pero en sistemas de muy baja potencia o bajo costo o bajo especificaciones es importante.
Lea otras preguntas en las etiquetas protocol networking