TCP offload engine
Este artigo ou se(c)ção está a ser traduzido. |
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
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. À 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
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
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.
Links externos (em inglês)
- Article: TCP Offload to the Rescue by Andy Currid at ACM Queue
- Patent Application 20040042487
- Mogul, Jeffrey C. (2003). «TCP offload is a dumb idea whose time has come» (PDF). Proceedings of HotOS IX: The 9th Workshop on Hot Topics in Operating Systems. USENIX Association. Consultado em 23 July 2006 Verifique data em:
|acessodata=
(ajuda) - «TCP/IP offload Engine (TOE)». 10 Gigabit Ethernet Alliance. April 2002 Verifique data em:
|data=
(ajuda)
- ↑ Jonathan Corbet (1 de agosto de 2007). «Large receive offload». LWN.net. Consultado em 22 de agosto de 2007
- ↑ Aravind Menon, Willy Zwaenepoel (28 de abril de 2008). «Optimizing TCP Receive Performance»