커널은 언제 UDP 데이터그램을 MTU 청크로 자르나요?

커널은 언제 UDP 데이터그램을 MTU 청크로 자르나요?

제가 겪고 있는 문제에 대한 여러분의 도움/팁/의견이 필요합니다. 감사해요

몇 가지 상황은 다음과 같습니다. 최대 크기가 1700바이트인 PDU를 처리하는 두 개의 응용 프로그램(A1 및 A2)이 있습니다. 각 애플리케이션은 서로 다른 카드(C1 및 C2)에 있으며 1Gbps 이더넷을 사용하여 서로 직접 연결되어 있으며 두 애플리케이션 모두 UDP 소켓을 사용하여 보내고 받습니다. C2 카드는 C1, A1, A2보다 더 강력합니다.

PDU의 길이는 최대 1700바이트일 수 있지만 각 애플리케이션이 PDU를 보내고 받을 때 길이는 1450바이트를 초과할 수 없습니다. 따라서 일반적인 1500바이트 MTU의 경우 PDU와 이더넷 프레임 간에 1:1 매핑이 이루어집니다.

가장 강력한 카드인 C1이 약 90Mbps에서 100% CPU 사용량을 달성한 가장 높은 데이터 속도(~125Mbps FYI)를 제외하고는 다양한 데이터 속도에서 모든 것이 잘 작동했습니다.

저는 네트워크 통신을 연구하면서 글로벌 성과를 향상시킬 수 있는 방법을 찾기 시작했습니다. 모든 것이 작동하기 전에 나는 연결된 UDP 소켓을 사용하기로 결정했습니다. 커널의 몇 단계를 우회하면 더 빠르다는 내용을 읽었기 때문입니다. 따라서 연결되지 않은 대응 요소를 구현하는 데 시간을 들이지 않았기 때문에 더 낫다고 생각합니다.

비고 0: UDP 연결 소켓이 더 빠르게 응답하는 이유에 대해 어떤 주장도 받아들일 수 있습니다.

그런 다음 C1과 C2 사이의 MTU를 늘리기 시작했습니다. ==> 여전히 send유선을 통해 최대 1450바이트 PDU를 전송하고 있었기 때문에 개선이 없었습니다.

다음 단계: PDU 집합. PDU를 차례로 보내는 대신 약 60KB의 큰 UDP 데이터그램으로 집계하여 MTU가 1500인 라인을 통해 보냈습니다. ==> 개선 없음(커널은 어떤 지점 보고서에서 빅 데이터를 잘라내고 이더넷 프레임) 상대방에서는 패킷 손실이 없으므로 메커니즘이 괜찮을 것입니다.

질문 1: 궁금해서, 커널은 언제 내 데이터를 더 작은(MTU와 같은) 데이터로 자르나요? IP로 보내기 직전에? 이더넷 이전? 낮추다? (그럼 NIC가 책임이 있다는 건가요?)

마지막 단계: 양쪽에서 더 큰 MTU(3000 5000 6000 8192)를 사용하여 집계된 PDU를 보냅니다. 여기에 문제가 있습니다.MTU를 더 많이 늘릴수록 더 많은 오류가 발생합니다!

질문 2: 이런 일을 겪어본 사람이 있나요? 두 카드 모듈 모두 이더넷 점보 프레임을 지원할 것으로 예상됩니다. 어떻게 그래? 어디를 봐야 할지에 대한 조언이 있나요?

참고로 병목 현상 카드 C1은 커널 2.6.23을 실행하고 있으므로 sendmmsg유사한 옵션을 사용할 수 없습니다.

자세한 내용은 카드 2장씩 2세트를 가지고 있습니다. C2는 트래픽 생성기에서 125Mbps를 검색하여(한 번에 1PDU) 이를 C1에 보내고(한 번에 1PDU), C1은 무선으로 데이터 스트림을 보냅니다(한 번에 여러 PDU). C1'은 방송 중인 데이터를 캡처하고(방법은 모르겠습니다. 마술입니다)(한 번에 여러 개의 PDus) 그런 다음 이를 C2'로 보냅니다(한 번에 하나씩, 작동하지 않으므로 한 번에 여러 개 보내보세요) C2' 데이터를 전송하여 루프를 종료하면 트래픽 생성기로 다시 돌아와 이전에 전송된 데이터와 비교하고 많은 세부 정보를 인쇄합니다.

시간 내 주셔서 감사합니다,

삭스

관련 정보