카더라가 좀 많아서 몇 가지 정리 좀 하겠습니다.
1. iWARP/ROCE/RDMA가 동일한 기술은 아닙니다.
전혀. iWARP를 지원하는 NIC중에 RDMA를 지원하지 않는 NIC들이 많습니다.
2. RDMA가 ZERO COPY이기 때문에 성능이 좋은건 아닙니다.
TCP/IP도 ZERO COPY로 구현된지 10년 넘었습니다.
다만 RDMA가 ZERO COPY인건 태생적으로 맞습니다.
3. 모든 10G/40G가 RDMA를 지원하지는 않지만 RDMA를 지원하는 카드는 많습니다. 또한 많은 >10G NIC들은 iWARP를 지원합니다.
4. RDMA/iWARP는 빠른 TCP가 아닙니다. 굳이 비교하려면 RDP (Reliable Diagram) 와 비슷하겠습니다.
5. RDMA의 DMA가 보안에 취약함. 웃기는 소리입니다.
RDMA가 REMOTE DMA입니다. 기본적으로 PC1의 메모리를 PC2에서 사용할 수 있는겁니다.
이걸가지고 보안이 어쩌구 하는것 자체가 웃기는 겁니다.
물론 프로그램 잘못짜면 위험할 수 있습니다.
아주 오래전에 어떤 회사가 요청했던 비슷한 상황이 있었습니다. 반도체/디스플레이 QA 쪽 솔루션 이었습니다.
그때 상황은
1. PC1의 카메라가 워이퍼/패널 사진을 찍음
2. PC1의 카메라가 찍은 이미지를 파일로 떨꿈 (Local DISK/NFS/SAMBA 등 다양한 방법 사용)
3. PC1이 PC2 (분석장비)에 파일이 생성되었음을 알림
4. PC2가 PC1의 파일을 가져감 (보내줌, NFS/SAMBA 등 공유 저장장치에 저장함 등등)
5. PC2는 해당 파일을 읽고 (메모리로 로딩) "분석" 함
순이었습니다.
문제는 파일의 크기가 점점 커지면서 촬영/저장/전송/분석 단계 중에서 저장/전송 단계에 너무 많은 시간/자원이 소요 되는 거였습니다.
해결방법은
1. PC1의 카메라가 사진을 찍음
2. PC1의 카메라가 찍은 IMAGE DATA가 아직 BUFFER에 있음 (Driver buffer 일수도 있음)
3. PC1은 해당 DATA가 저장된 메모리의 위치를 확인함 (메모리에 Lock걸구, 간혹 LOCK 빼먹으면 5와 같은 보안 이슈 발생 할 수 있음)
4. PC1은 PC2에 해당 메모리 위치/크기 등을 알려 줌
5. PC2는 PC1의 메모리에서 IMAGE DATA를 RDMA Protocol을 사용하여 PC2의 메모리로 가져옴
6. PC2는 PC1의 해당 메모리 LOCK 해제
7. PC2는 이미 자신의 메모리에 있는 데이터를 대상으로 "분석" 수행 함
이었습니다.
데모 수준에서 해보면 10~40배 정도의 성능 향상이 이루어 지는 걸 확인 할 수 있는데
이 간단한 구조를 실제 구현 하는게 만만치 않습니다.
당시 개발팀장 비명 소리가 지금도 생생합니다.
보안에 취약하다고 한적은 없습니다.
intel cpu 게이트 발생하면서 덤으로 xeon DDIO. RDMA의 경우 보안 취약점이 발견된적이 있었으니 어떻게 해결되었는진 모르겠다 정도로만 언급했습니다.
그래서 아래의 링크를 걸어놨던 것이구요.
https://www.bodnara.co.kr/bbs/article.html?num=157569
개인적으로 10G 구성해서 써본적이 없어서 질문도 곁들여 봅니다.
RDMA 구성없이 10G 만으로 파일을 주고 받을수 있는건가요? 원 질문자도 10G 가 RDMA 없이 어떻게 가능하냐고 반문하셨는데 궁금합니다.
10G samba나 nfs 등으로 말이죠.
일반 TCP로도 다 되는 부분입니다.
다만 RDMA가 A장치에서 B장치의 메모리를 사용할 수 있도록 허용한 구조/기술인데 이를 보안 취약으로 비교하는 건 좀 맞지 않아 보입니다.
질문자의 질문을 잘 보면 파일을 전송한다고 하지 않았습니다.
그렇기 때문에 그걸 NFS/SAMBA로 전송이 가능하냐 하고 하시면 이는 또 전혀 다른 질문으로 보입니다.
전송되는 데이터가 파일이라면
10G로 10G 전송이 어려우면 100G 쓰면 가능할 수도 있겠죠
그런데 양쪽의 DISK가 적절하지 않으면 100G아니라 400G로도 힘들겠죠
굳이 비교하자면 내 차가 200KM/h를 달릴 수 있어도 서울시내에선 어렵겠죠.
아무튼 파일을 전송한다는 말이 없는게 의외의 핵심 키워드였나 보네요. 생각이 짧았습니다.
개인적으로는 왜 굳이 촬영과 처리가 다른 장치에서 되어야 하나. 복사의 시간을 줄이는게 최선이라면
동일 장비에서 처리하고 다른 컴퓨터를 mpi 등을 이용하여 처리용 데이터나 연산만 떠넘겨
더 성능향상을 꾀할수 있지 않을까?라는 생각이 들었는데 반도체 장비라 원 기능 이외에 다른 기능으로 쓰지 못하는
모종의 제약이 있으니 그런 생각을 하는 건 아닐까 했습니다.
2. 현재의 리눅스 TCP 스택이 정말로 zero-copy일까요? 결국 애플리케이션에서 그 데이터를 사용하려면 커널 메모리->유저 메모리로 추가적인 copy가 필요합니다.
이 부분을 제거하기 위해 uio를 구현하기도 해 본 입장에서 zero copy가 상당한 비중을 차지하는 것도 맞습니다. zero copy가 전부가 아니라는 점에는 동의합니다.
참고로 100G 스루풋 테스트를 할 때 커널 네트워크 스택으로는 성능이 안 나와서 DPDK를 사용했습니다. 40G 까지는 어떻게든 커버한다 쳐도 100G 부터는 RDMA를 쓰는 편이 오히려 더 쉽고 빠르게 하이 스루풋을 달성할 수 있는 방법이 아닐까 생각합니다. 개인적인 의견입니다.
=>초기 INTEL iWARP NIC들 중에서 RDMA 지원하지 않는 NIC들 많았습니다. CHELSIO도 마찬가지 였습니다.
2. 현재의 리눅스 TCP 스택이 정말로 zero-copy일까요?
=> ZERO COPY 맞습니다. 그렇지 않게 구현된 DRIVER/STACK도 있긴 합니다.
=> Applicartion에서 어떻게 구현이 되었는지는 전혀 다른 또 다른 영역입니다.
별도 이슈지만 (저는 개인적으로 DPDK로 뭔가를 만들어본 경험은 없습니다)
DPDK는 네트워크 패킷처리를 하는 Protocol이고 RDMA는 Remote DMA입니다.
DPDK는 User Space에서 NIC 레벨의 네트워크를 콘트롤 할 수 있는 Library 모음이라서 포텐셜이 있다고 말들 합니다.
문제는 DPDK는 L2 수준의 Protocol을 L6 수준에서 사용할 수 있도록 하기 때문에 User Space Application 에서 엄청난 성능을 낼 수 있겠지만 개발 난이도 역시 엄청날 겁니다.
예를 들어서 DPDK에서는 형식화된 통신 프로토콜이 아니기 때문에 개발자가 어떤 데이터를 전송/받기 등을 하려면 이 모든 콘트롤을 직접 개발해야 합니다.
즉, TCP 같은 프로토콜을 Application 개발자가 개발해서 솔루션에 넣어야 하는 겁니다.
만만치 않죠
원 질문자가 질문한 내용의 답 비슷한 걸 찾으려면
=>PC2에서 작동하는 분석 프로그램이 PC1의 CAMERA가 찍은 데이터를 PC1의 메모리에 가지고 있을 테니까 이를 직접 알아서 가져오는 프로그램/시스템을 만들어야 합니다.
DPDK로 만들 수 있습니다.
RDMA로도 만들 수 있습니다.
난이도야 뭐..
2. 그러니 Application에서 '최소한' 한 번의 copy는 필요하다는 이야기입니다. RDMA의 이득이 가장 적은 경우라 하더라도 RDMA는 최소한 한 번의 memcpy를 제거할 수 있습니다. 그리고 아시다시피 그 한 번의 차이는 애플리케이션에 따라서는 상당히 클 수 있습니다
3. DPDK는 L2 Library고, 때문에 상위 프로토콜 스택을 라이브러리로 제공하는 mTCP 같은 서드파티 라이브러리가 존재합니다. 물론 안정성은 상대적으로 떨어집니다...
불안정성+미친듯이 치솟는 개발 난이도 때문에 over 40G를 구현하기 위해 굳이 DPDK를 사용하기보다는 차라리 IB Verbs API를 공부하는 편이 더 나을 수도 있다는 것입니다. DPDK를 사용해 본 입장에서요..
사실 이미 오늘 오전에 글 작성자분과 통화하여 현재의 bottleneck point는 latency 보다는 bandwidth이니, 100/200G NIC을 구매하여 일단 현재의 전송 프로토콜로 쓰루풋/목표 시간 만족 여부를 확인한 뒤 만약 충분치 않으면 RDMA를 옵션으로 고려하라고 조언을 드렸습니다. 아마 그렇게 진행을 하실 겁니다.
개인적으로는 쓰레드를 잘 쪼개서 이미지를 분할 전송할 수 있다면 CPU 코어에 잘 분산해서 near 100G 까지는 구현할 수 있을 것으로 보고 있습니다. 시스템 성능에 달린 문제죠. 만약 그것으로도 불충분하다면 RDMA를 사용해야 할 수도 있습니다.
DPDK가 아직 무르익은 기술도 아니고 개발난이도가 상당합니다.
또한 DPDK를 지원하는 NIC이 많지 않을 겁니다.
만약 DPDK가 어느정도 자리를 잡으면 NIC 제조사들이 이를 더 잘 지원할 것이고 그러면 지금 보시는 한계도 빨리 사라질 수 있습니다.
마치 그래픽 카드가 driver 개선으로 성능이 좋아지는 것 처럼요
뭐, 아닐수도
파일도 part 형태로 split하여 병렬프로세서로 하는걸 선호합니다,.
단일은 이어받기가 어렵지만 시피유갈궈서 분할해두면 편하기때문에요...