TCP offload engine

Origem: Wikipédia, a enciclopédia livre.

TCP offload engine ou TOE é uma tecnologia usada em Interfaces de rede (NIC) para descarregar o processamento de entrada de toda a pilha TCP/IP para o controlador de rede. Ele é usado principalmente com interfaces de rede de alta velocidade, tais como Gigabit Ethernet e Rede 10-Gigabit Ethernet, onde a sobrecarga de processamento da pilha de rede torna-se significativo.

O termo TOE é muitas vezes usado para referir-se a placa de rede, embora os engenheiros da placa de circuito podem usá-lo para se referir apenas ao circuito integrado incluído no cartão que processa os cabeçalhos TCP. TOE é muitas vezes sugerido como uma forma de reduzir a sobrecarga associada a protocolos de armazenamento IP, tais como iSCSI e NFS.

Propósito[editar | editar código-fonte]

Originalmente o TCP foi desenvolvido para redes não confiáveis de baixa velocidade (como em conexões de Acesso discado/Modems dial-up), mas com o crescimento da Internet em termos de velocidade de transmissão nos backbones (links de Fibra Óptica, Gigabit Ethernet e 10 Gigabit Ethernet) e mecanismos de acesso mais rápidos e confiáveis (como ADSL e Cable Modems) ele passou a ser frequentemente utilizado em ambientes de data centers e PC's em velocidades de até 1 gigabit por segundo. As implementações de software TCP exigem grande poder de computação nos sistemas das máquinas. A comunicação Full duplex TCP por si só é suficiente para consumir 80% de um processador 2.4 Ghz Pentium 4 (ver #Ciclos de CPU liberados), resultando em poucos ou nenhum recurso de processamento para os aplicativos que estão em execução no sistema.

Como o TCP é um protocolo orientado a conexão, isto aumenta a complexidade e a sobrecarga de processamento do protocolo. Estes aspectos incluem:

  • Estabelecimento da conexão usando o aperto de mão de três vias ("3-way handshake") - SYNchronize; SYNchronize-ACKnowledge; ACKnowledge.
  • Reconhecimento de pacotes à medida que forem recebidos pela extremidade, somando-se o fluxo de mensagens entre os pontos finais e assim a carga de protocolo.
  • Cálculos de Checksum e número de seqüência - novamente um fardo à ser executado por uma CPU de propósito geral.
  • Cálculos de Sliding window para reconhecimento de pacotes e controle de congestionamento
  • Término da conexão

Transferindo todas essas funções ou parte delas para um hardware dedicado, o TCP offload engine, libera o CPU principal do sistema para outras tarefas. A partir de 2012, muito poucas interfaces de rede do consumidor suportam TOE.

Em vez de substituir a pilha TCP totalmente com o TOE, existem técnicas alternativas para descarregar algumas operações em cooperação com a pilha TCP do sistema operacional. TCP checksum offload e large segment offload são suportados pela maioria das interfaces de rede ethernet de hoje. Técnicas mais recentes, como large receive offload e TCP acknowledgment offload já são implementadas em alguns hardwares ethernet de alta qualidade, mas são eficazes mesmo quando implementadas exclusivamente em software [1][2]

Ciclos de CPU liberados[editar | editar código-fonte]

Uma regra de ouro geralmente aceita é que um hertz de processamento da CPU é necessário para enviar ou receber 1 bit/s de TCP/IP [3]. Por exemplo, 5 Gbit/s (625 MB/s) de tráfego de rede requer 5 GHz de processamento da CPU. Isto implica que dois núcleos inteiros de um processador multi-core de 2.5 GHz serão necessários para lidar com o processamento TCP/IP associado com 5 Gbit/s de tráfego TCP/IP. Considerando que Ethernet (10Ge neste exemplo) é bidirecional, é possível enviar e receber 10 Gbit/s (para um throughput agregado de 20 Gbit/s). Usando a regra de 1 Hz/(bit/s) isso equivale a oito núcleos de 2.5 GHz.

Muitos dos ciclos de CPU utilizado para o processamento TCP/IP são "libertados" por de TCP/IP offload e pode ser usado pelo processador central (geralmente a CPU de um servidor) para realizar outras tarefas, tais como o processamento de sistema de arquivos (num servidor de arquivos) ou a indexação (em um servidor de backup). Em outras palavras, um servidor com TCP/IP offload pode fazer mais trabalho de servidor do que um servidor sem placas que suportam TCP/IP Offload.

Redução do tráfego PCI[editar | editar código-fonte]

Além do overhead de protocolo que o TOE pode abordar, ele também pode solucionar alguns problemas arquitetônicos que afetam uma grande porcentagem de endpoints baseados em host (servidor e PC). Muitos hosts de ponto de extremidade mais antigos são baseados em barramento PCI, que fornece uma interface padrão para a adição de certos periféricos, tais como Interfaces de Rede para Servidores e Computadores . O PCI é ineficiente para transferir pequenos rajadas de dados da memória principal, através do barramento PCI para os CIs da interface de rede, mas sua eficiência melhora à medida que aumenta o tamanho do estouro de dados (burst-size). Dentro do protocolo TCP, um grande número de pequenos pacotes são criados (por exemplo, reconhecimentos) e como estes são tipicamente gerados na CPU do host e transmitidos através do barramento PCI e fora da interface física da rede, isso afeta a taxa de transferência de E/S do host servidor (throughput I/O do host servidor).

Uma solução TOE, localizada na interface de rede, está localizada no outro lado do barramento PCI a partir do CPU do host para que ele possa solucionar esse problema de eficiência de E/S, pois os dados a serem enviados através da conexão TCP podem ser enviados para o TOE da CPU através do barramento PCI usando grandes rajadas de dados (data burst) com nenhum dos pacotes TCP menores precisando percorrer o barramento PCI.

História[editar | editar código-fonte]

Uma das primeiras patentes dessa tecnologia, para UDP Offload (descarregamento de UDP, em tradução livre), foi emitida a Auspex Systems no início de 1990. Erro de citação: Elemento de fecho </ref> em falta para o elemento <ref>

Em 2002, quando o surgimento do armazenamento baseado em TCP (como iSCSI) estimulou o interesse, foi dito que "pelo menos uma dúzia de recém-chegados, a maioria fundada no final da bolha pontocom, está perseguindo a oportunidade para comercializar aceleradores de semicondutores para protocolos de armazenamento e aplicações, competindo com meia dúzia de fornecedores entrincheirados e projetos internos de ASIC.[3]

Em 2005, a Microsoft licenciou a base de patentes da Alacritech e, juntamente com a Alacritech, criou a arquitetura de descarga parcial de TCP que se tornou conhecida como "TCP chimney offload" (descarga de chaminé TCP, em tradução livre). Ao mesmo tempo, a Broadcom também obteve uma licença para construir chips de transferência TCP chimney offload.

Tipos de TCP/IP offload[editar | editar código-fonte]

Descarregamento completo de pilha paralela[editar | editar código-fonte]

O descarregamento completo de pilha paralela (Parallel-stack full offload) recebe esse nome devido ao conceito de duas pilhas TCP/IP paralelas. A primeira é a pilha do host principal incluída no sistema operacional deste host. A segunda ou "pilha paralela" é conectada entre a Camada de aplicação e a Camada de transporte (TCP) usando um "toque de vampiro". O vampire tap intercepta solicitações de conexão TCP por aplicativos e é responsável pelo gerenciamento da conexão TCP, bem como pela transferência de dados TCP. Muitas das críticas na seção a seguir se referem a esse tipo de TCP offload.

Descarregamento total do HBA[editar | editar código-fonte]

O descarregamento completo de HBA (Host Bus Adapter) é encontrado em adaptadores host iSCSI que se apresentam como controladores de disco ao sistema host durante a conexão (via TCP/IP) a um dispositivo de armazenamento iSCSI. Esse tipo de descarregamento de TCP não apenas descarrega o processamento TCP/IP, mas também descarrega a função do iniciador iSCSI. Como o HBA aparece para o host como um controlador de disco, ele só pode ser usado com dispositivos iSCSI e não é apropriado para o descarregamento geral de TCP/IP.

Links externos (em inglês)[editar | editar código-fonte]

  1. Jonathan Corbet (1 de agosto de 2007). «Large receive offload». LWN.net. Consultado em 22 de agosto de 2007 
  2. Aravind Menon, Willy Zwaenepoel (28 de abril de 2008). «Optimizing TCP Receive Performance» 
  3. ""recém-chegados spin armazenamento de silício rede", Rick Merritt,10/21/2002, EE Times