카더라가 1328; 많아서 ኧ1; 가1648; 1221;리 1328; Ȣ16;,192;습니다.
1. iWARP/ROCE/RDMA가 ᇼ1;1068;한 기술1008; 아닙니다.  
1204;혀.  iWARP를 1648;원Ȣ16;lj16; NIC1473;에 RDMA를 1648;원Ȣ16;1648; 않lj16; NIC들1060; 많습니다.
2. RDMA가 ZERO COPY1060;기 ǐ12;문에 성능1060; 1339;1008;,148; 아닙니다.  
TCP/IP도 ZERO COPY/196; 구현.108;1648; 10년 넘었습니다.  
다만 RDMA가 ZERO COPY1064;,148; 태생1201;1004;/196; 맞습니다.
3. 모든 10G/40G가 RDMA를 1648;원Ȣ16;1648;lj16; 않1648;만 RDMA를 1648;원Ȣ16;lj16; 카드lj16; 많습니다.  또한 많1008; >10G NIC들1008; iWARP를 1648;원합니다.
4. RDMA/iWARPlj16; 빠른 TCP가 아닙니다.  굳1060; 비교Ȣ16;/140;면 RDP (Reliable Diagram) 와 비슷Ȣ16;,192;습니다.
5. RDMA1032; DMA가 보안에 ȏ12;약함.  웃기lj16; 소리1077;니다.  
RDMA가 REMOTE DMA1077;니다.  기본1201;1004;/196; PC11032; 메모리를 PC2에서 사용할 수 1080;lj16;,161;니다.
1060;,152;가1648;고 보안1060; Ǻ12;1788;구 Ȣ16;lj16;,163; 1088;체가 웃기lj16; ,161;니다.
물론 프/196;그ǖ16; 1096;못1676;면 위험할 수 1080;습니다.
아1452; 오래1204;에 Ǻ12;떤 회사가 요청했Nj12; 비슷한 상황1060; 1080;었습니다.  0152;도체/디스플/112;1060; QA 1901; 솔루션 1060;었습니다.
그ǐ12; 상황1008;
1. PC11032; 카메라가 워1060;6140;/패널 사1652;1012; 찍1020;
2. PC11032; 카메라가 찍1008; 1060;0120;1648;를 파1068;/196; 떨꿈 (Local DISK/NFS/SAMBA መ1; 다양한 0169;법 사용)
3. PC11060; PC2 (ǥ16;석1109;비)에 파1068;1060; 생성.104;었1020;1012; 알림
4. PC2가 PC11032; 파1068;1012; 가1256;감 (보내1468;, NFS/SAMBA መ1; 공유 1200;1109;1109;치에 1200;1109;함 መ1;መ1;)
5. PC2lj16; 해NJ17; 파1068;1012; 1069;고 (메모리/196; /196;딩) "ǥ16;석" 함
순1060;었습니다.
문1228;lj16; 파1068;1032; 크기가 1216;1216; 커1648;면서 촬영/1200;1109;/1204;송/ǥ16;석 단계 1473;에서 1200;1109;/1204;송 단계에 너무 많1008; 시간/1088;원1060; 소요 .104;lj16; ,144;였습니다.
해결0169;법1008;
1. PC11032; 카메라가 사1652;1012; 찍1020;
2. PC11032; 카메라가 찍1008; IMAGE DATA가 아1649; BUFFER에 1080;1020; (Driver buffer 1068;수도 1080;1020;)
3. PC11008; 해NJ17; DATA가 1200;1109;.108; 메모리1032; 위치를 확1064;함 (메모리에 Lock,152;구, 간ᕬ1; LOCK 빼먹1004;면 5와 같1008; 보안 1060;슈 0156;생 할 수 1080;1020;)
4. PC11008; PC2에 해NJ17; 메모리 위치/크기 መ1;1012; 알/140; 1468;
5. PC2lj16; PC11032; 메모리에서 IMAGE DATA를 RDMA Protocol1012; 사용Ȣ16;여 PC21032; 메모리/196; 가1256;옴
6. PC2lj16; PC11032; 해NJ17; 메모리 LOCK 해1228;
7. PC2lj16; 1060;0120; 1088;신1032; 메모리에 1080;lj16; 데1060;터를 대상1004;/196; "ǥ16;석" 수행 함
1060;었습니다.
데모 수1456;에서 해보면 10~400176; 1221;도1032; 성능 향상1060; 1060;루Ǻ12; 1648;lj16; ,152; 확1064; 할 수 1080;lj16;데
1060; 간단한 구1312;를 실1228; 구현 Ȣ16;lj16;,172; 만만치 않습니다.
NJ17;시 개0156;Ȝ16;1109; 비명 소리가 1648;금도 생생합니다.
보안에 취약하다고 한적은 없습니다.
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하여 병렬프로세서로 하는걸 선호합니다,.
단일은 이어받기가 어렵지만 시피유갈궈서 분할해두면 편하기때문에요...