고급 NIC에서 GRO (일반 수신 오프로드) 작동 방식

특정 답변에 관심이 있습니다.

1. GRO가있는 NIC가 TCP ACK 또는 다른 패킷을 편집 / 생성합니까 (또는이 기능이 수신자 / 전송자 TCP 스택에 투명합니까?)?
2. NIC가 "접착 된 세그먼트"를 TCP 스택으로 전달해야하는 시간 초과 / 이벤트가 있어야합니까? 그들은 무엇인가?
3. 패킷 포워딩 설정에서 GRO 기능은 수신기 ACK를 읽으려고 시도합니까 (이를 묻는 이유는 아래 참조)?
4. Wikipedia 및 Linux 매뉴얼 페이지보다 GRO 및 기타 NIC 오프 로딩 기능 (TSO, LSO ...)을 설명하는 모든 소스가 정말 좋습니다.

자세한 내용은:

하나의 IPSec 구현으로 성능 문제를 해결하고 있습니다. 문제는 사용 가능한 대역폭이 모든 4 개의 VPN 터널에 균등하게 분배되지 않는다는 것입니다 (약 200MBps / 200MBps / 1MBps / 1MBps로 분배됩니다. 각 VPN 터널은 단일 TCP 연결을 캡슐화합니다). PCAP에서 가끔 웹 서버가 ~ 2 초 동안 유휴 상태임을 알 수 있습니다 (ACK 대기 중). 웹 서버가 승인되지 않은 세그먼트를 재전송하면 다운로드가 다시 시작됩니다.

PCAP에서 필자가 빠뜨린 것은 NIC GRO 기능이 패킷을 서로 접착하지만 때로는 적시에 TCP 스택으로 전달하지 않아 문제가 발생한다는 것입니다.

이 VPN 서버에는 TCP 연결을 종료하는 인터페이스가 없지만 패킷 만 전달합니다. 그런 다음 GRO를 비활성화하려고 시도한 후 트래픽이 모든 터널에 균등하게 분배되는 것을 관찰했습니다. 또한 웹 서버에서 TCP 창 스케일링을 비활성화하면 GRO를 활성화해도 대역폭이 분산됩니다 (따라서 질문 # 3이 발생했습니다).

Ubuntu 10.04 서버 (64 비트)에서 2.6.32-27 Linux를 사용하고 있습니다. NIC는 인텔 82571EB입니다. 모든 인터페이스 (HTTP 클라이언트, VPN 클라이언트, VPN 서버, 웹 서버)는 1Gbit 이더넷 케이블과 체인으로 직접 연결됩니다.

이 기사가 놀랍게도 유용하다는 것을 알았습니다 : JLS2009 : Generic receive offload . GRO 작동 방식에 대한 훌륭한 개요를 제공합니다.

1. 일부 어댑터가이를 수행 할 수 있지만 연관된 드라이버도 인식해야합니다. 또한 드라이버 자체가 소프트웨어에서이 작업을 수행 할 수 있습니다. 커널 TCP / IP 스택에 들어가기 전에 이런 일이 발생하므로 커널 공간 TCP / IP 스택이 완전히 입력 될 때까지 패킷이 다시 배열됩니다.
2. 제한 시간은 GRO 스펙에 의해 하나의 TCP / IP '틱 (tick)'(시간 소인 필드 증가)으로 정의되며, 이는 매우 작은 수이지만 빠른 네트워크에서는 여러 패킷이 여전히 수신 될 수 있습니다.
3. GRO는 포워더의 수신 측에서 작동하며 실제로 GRO는보다 욕심 많은 LRO 방법이 포워더의 패킷을 망칠 수 없도록 만들어졌습니다.
4. 위에 링크 된 기사가 실제로 도움이됩니다.

Ethtool 은 특정 인터페이스에서 GRO를 활성화 / 비활성화 할 수 있습니다. 버전에 따라 다릅니다.