현재 위치

홈 ›› Forums ›› 공부 ›› 프로그래밍 QnA

네트워크 패킷을 커널을 걸치지 않고 받을 수 있습니까??

ins878의 이미지
글쓴이: ins878 / 작성시간: 화, 2004/05/18 - 10:42오후

안녕하세요~ 네트워크 프로그래밍에 관심이 많은 어설픈 프로그래머입니다.~~ㅋㅋㅋ

다름이 아니라, 몇 일전에 누가와 얘기를 하게되었는데, 패킷을 커널을 걸치지 않고 바로 캡쳐할 수 있다는군요.
제가 알기로는 패킷은 커널모드에서 잡을 수 있고, 애플리케이션(대표적으로 libpcap)에서 잡을 수 있는 걸로 알고있는데, 커널을 걸치지 않고 바로 캡쳐를하면 속도가 무지하게 빠르다는 말을 들었습니다.
그게 가능한가요? 그리고, 만약 가능하다면, 어떤식으로 가능한지~~, 또 그런 자료를 찾을 수 있는지 궁금합니다. 고수님들의 조언부탁드립니다.

File attachments: 
첨부파일 크기
Image icon io.gif26.9 KB
Image icon socket.gif39.18 KB
Forums: 
프로그래밍 QnA
mach의 이미지

글쓴이: mach / 작성시간: 목, 2004/05/20 - 8:41오후

ins878 wrote:

다름이 아니라, 몇 일전에 누가와 얘기를 하게되었는데, 패킷을 커널을 걸치지 않고 바로 캡쳐할 수 있다는군요.
제가 알기로는 패킷은 커널모드에서 잡을 수 있고, 애플리케이션(대표적으로 libpcap)에서 잡을 수 있는 걸로 알고있는데, 커널을 걸치지 않고 바로 캡쳐를하면 속도가 무지하게 빠르다는 말을 들었습니다.
그게 가능한가요? 그리고, 만약 가능하다면, 어떤식으로 가능한지~~,

이해를 위해 data path와 control path를 먼저 정의하지요.
data path는 버퍼(buffer;메모리)의 흐름입니다. 데이터흐름. 데이터플로우, 버퍼복사.....
control path는 machine 명령어(복사하라!라는...)로 보면됩니다.

이때, 커널을 경유하지 않는다는 것은 데이터가 커널의 자료구조(또는 버퍼)를
사용하지 않는다는 것을 의미합니다. 다시말해 data path가 커널을
경유하지 않는다는 말이지요.

따라서, 네트워크 디바이스->커널버퍼->사용자버퍼(응용버퍼)로의 버퍼복사를
줄여서 0 copy(zero copy)로 데이터가 사용자 영역버퍼에 도착하게 하여 속도가
빠르게 된다는 얘기입니다. 이를테면 네트워크 디바이스의 드라이버를 손봐서,
네트워크 디바이스가 데이터 수신시 PCI버스를 마스터링하여 사용자 영역
메모리에 직접 데이터를 쓰게된다는 예를 들 수 있습니다.
이 경우에도, 디바이스 드라이버코드(제어코드)는 커널에 있게 되겠지요.
그러나, 그 드라이버가 사용하는 버퍼는 사용자 영역에 위치시키는것입니다.
그래서 데이터 경로가 커널을 거치지 않는다. 이게 맞는 말이 되겠지요.

* 참고: 파일시스템의 경우도 블럭디바이스가 커널의 버퍼캐시를 경유하는,
데이터 경로를 가지는 것을 우회하게(커널 안거치게)하여 성능을 개선할 수 있습니다.

ins878 wrote:

제가 알기로는 패킷은 커널모드에서 잡을 수 있고, 애플리케이션(대표적으로 libpcap)에서 잡을 수 있는 걸로 알고있는데

pcap의 내부구현이 정확히 어떻게 되는지는 모르지만, 커널의 특정영역(휘발성커널버퍼)에 패킷을 저장하고,
휘발성이므로 만일, 빠른 속도로 오는 패킷을, 사용자프로그램이 전부 가져가지 못한다면 기존 버퍼에 신규 패킷을 덮어쓰게(손실)되겠지요.
휘발성일 수 밖에 없는것은 passive모드(느리게 주던 빠르게 주던, 주는대로 받기만하는.....)이기 때문입니다. 라우터나 f/w, 게이트웨이
같이 active하게 네트워크 흐름제어를 수행할 수 없는 라이브러리이기 때문입니다.

여기서 잠시 생각하면, 전형적인 구조인 커널내의 패킷처리구현에서 커널버퍼를 늘리면
성능이 다소 증가할 수 있을것입니다. 윈도우의 pcap구현에서는 이를 환형버퍼로 구현해서
성능을 다소 증가시켰다는 논문이 있었고요. 환형버퍼가 성능개선한게
아니고, 버퍼크기가 성능개선했다는게 맞겠지요?!! 이 논문은 winpcap홈페이지에
있을겁니다.
아니면, pcap이 zero copy로 사용자 프로그램(응용프로그램)의 버퍼로 쓰게
한다면, 버퍼복사줄임으로 인한 성능증가가 예상됩니다.
여기서, 이러한 환형버퍼를 사용자영역에 또 구현하는것은 보탬이 되기 힘듭니다. 8)
역시 버퍼복사 줄이는게 성능개선에는 가장 좋은 방법입니다.

pcap의 가장 큰 장점은 많은 패킷 capture라이브러리중 가장 포터빌리티가 뛰어나다는 것일것입니다.

pcap_recv()->가물가물...??대충 이런 사용자 API를 통해 커널에서부터 사용자로 버퍼
복사를 받아서 이를 여러가지 방법으로 처리하겠지요.
이러한 일련의 절차에 대한 처리속도가 pcap의 효율을 결정하는데 중요한 요소가
될 것입니다.
pcap은 성능(효율?)보다는 portability에 치중된 라이브러리라고 볼수 있겠습니다.
그러나, 성능도 그리 나쁜것같지는 않습니다. 쓸만하다고 봅니다.

성능을 강조한다면 당연히 포터빌리티는 떨어질 수 밖에 없겠지요? 특정
운영체제에서만 동작한다던지 모 이런 시나리오가 예상됩니다.

항상 일장일단이 있기 마련이겠지요? :shock:

ins878 wrote:

또 그런 자료를 찾을 수 있는지 궁금합니다.

이러한 시도에 대한 자료는 user-level communication + zero copy라는
키워드를 관련해서 찾아볼 수 있습니다.
기본적으로 디바이스드라이버를 제작하는 기술이 필요하고, 각종 프로토콜
핸들링에 대한 지식이 필요합니다. TCP/IP protocol suite에 속한 프로토콜도
알 필요가 있을수도.....
음 저는 약 7-9년전(?) unet(코넬대학)이 한참 이슈가 되었을때 잠시 관심을 가졌었고(가물가물~),
그후 via로 넘어가는 순간부터 관심을 끊었습니다(먹고살기바빠서). 현재, RDMA등으로 활발하게(?) 연구가되고 있다는 .....

------------------ P.S. --------------
지식은 오픈해서 검증받아야 산지식이된다고 동네 아저씨가 그러더라.

sjpark의 이미지

글쓴이: sjpark / 작성시간: 금, 2004/05/21 - 11:35오후

좋은 답글 감사합니다. :)

제가 질문 한건 아니지만, 궁금한것이 쏴악 풀렸어요..

ps. 게시물 스크랩 해용..

https://nicesj.com
https://blog.nicesj.com

toy의 이미지

글쓴이: toy / 작성시간: 토, 2004/05/22 - 8:12오전

예전에 커널을 거치지 않고 직접 유저영역에 쓰면 더빨라질거라는 생각을 잠시했었는데 실제로 있었군요.
zero-copy라는 개념은
디바이스 내부 캐시 -> 커널 -> 유저영역 ( 이 아니라...)
디바이스 내부 캐시 -> 유저영역 (이라고 이해하면 될런지요.)

그렇다면 왜 이렇게 성능이 좋은것을 리눅스 커널은 적용하지 않았을까 궁금합니다.... :oops: :oops: :oops:

blacknblue의 이미지

글쓴이: blacknblue / 작성시간: 토, 2004/05/22 - 9:20오전

math 님 고수시네요...^^

girneter의 이미지

글쓴이: girneter / 작성시간: 토, 2004/05/22 - 9:23오전

toy wrote:
예전에 커널을 거치지 않고 직접 유저영역에 쓰면 더빨라질거라는 생각을 잠시했었는데 실제로 있었군요.
zero-copy라는 개념은
디바이스 내부 캐시 -> 커널 -> 유저영역 ( 이 아니라...)
디바이스 내부 캐시 -> 유저영역 (이라고 이해하면 될런지요.)

그렇다면 왜 이렇게 성능이 좋은것을 리눅스 커널은 적용하지 않았을까 궁금합니다.... :oops: :oops: :oops:

커널에서 TCP/IP layer 를 거치면서 작업을 해야 하기 때문에 그렇겠죠.
디바이스 내부 캐쉬에 있는건 MAC layer 패킷일테니
이걸 유저한테 넘겨줘봤자 패킷캡처 이외의 용도로는 쓸모가 없습니다.

음식을 빨리 먹겠다고 날로 먹을 수는 없자나요? :D

개념없는 초딩들은 좋은 말로 할때 DC나 웃대가서 놀아라. 응?

dolsemix의 이미지

글쓴이: dolsemix / 작성시간: 토, 2004/05/22 - 6:12오후

girneter wrote:
음식을 빨리 먹겠다고 날로 먹을 수는 없자나요? :D

정말 절묘한 표현이십니다~

담배 고만 펴야겠다...

sozu의 이미지

글쓴이: sozu / 작성시간: 토, 2004/05/22 - 9:27오후

참고하실수 있는 논문은

http://os.korea.ac.kr/papers/domestic_journal/Asynchronous_UDP.pdf

이 있군요

제가 알기로는 Windows 에서의 Overlapped I/O Mechanism이

커널버퍼를 사용하지 않도록, 즉 버퍼링 오버헤드를 줄이도록 구현되어

있습니다.

댓글 첨부 파일: 
첨부파일 크기
Image icon 0바이트
Image icon 0바이트

-----------
청하가 제안하는 소프트웨어 엔지니어로써 재미있게 사는 법
http://sozu.tistory.com

toy의 이미지

글쓴이: toy / 작성시간: 토, 2004/05/22 - 10:04오후

그렇다면 윈도우에서는 tcp/ip스택에대한 처리도 유저영역의
메모리를 사용하게 된다는것인가요.......
커널에서 유저영역 메모리 공간을 사용한다는건 좀 위험하지 않을런지....요

sozu의 이미지

글쓴이: sozu / 작성시간: 일, 2004/05/23 - 5:07오후

toy wrote:
그렇다면 윈도우에서는 tcp/ip스택에대한 처리도 유저영역의
메모리를 사용하게 된다는것인가요.......
커널에서 유저영역 메모리 공간을 사용한다는건 좀 위험하지 않을런지....요

맞습니다. 논문에서도 비슷한 내용이 있습니다.

유저 영역의 버퍼를 넘겨주었다면 (I/O Request를 할때 넘겨줍니다.)

해당 I/O Request에 대한 Completion이 날때까지는 해당 버퍼를 건드리면

않됩니다.

몇가지 주의사항만 지켜준다면 그다지 위험하지는 않습니다.

-----------
청하가 제안하는 소프트웨어 엔지니어로써 재미있게 사는 법
http://sozu.tistory.com

dudungsil의 이미지

글쓴이: dudungsil / 작성시간: 일, 2004/05/23 - 8:19오후

쓰레드 주제가 win32 overlapped까지 오게 되었군요. 한때 유저 버퍼를 직접 제공함으로써 zero copy로 성능을 높인다는 말이 돌았던게 사실입니다만, 최근에는 사용하지 않는것으로 알고 있습니다.

최근에는 절대 사용하지 말라쪽에 가깝죠. 다음 URL을 참조하시기 바랍니다.
http://msdn.microsoft.com/msdnmag/issues/1000/Winsock/default.aspx

중간에 Who Manages the Buffers? 섹션을 보시면 될듯 하네요. 저자인 Anthony Jones는 network programming for windows를 쓴 이방면 최고 고수입니다. MS 소유의 MSDN 매거진 기사라는 것만으로 충분히 신뢰할만하기도 하지만요.

성능상 얻는 이점은 없습니다.

ps. iocp를 win32 overlapped로 수정했습니다. 관계도 없는 iocp를 왜 썼는지 모르겠군요 -_-

산넘어 산

sozu의 이미지

글쓴이: sozu / 작성시간: 일, 2004/05/23 - 8:45오후

좋은 글 감사합니다.

대충 읽어보았습니다. 한가지 의문점이 있습니다.

Quote:
Before going apoplectic over the buffer copying that's involved in sending and receiving data, a programmer should take great care to understand the consequences of turning off the buffering in AFD.SYS, which can be done by setting the SO_SNDBUF and SO_RCVBUF values to 0 using the setsockopt API.

이 방법은 알고 있었습니다만, 위에 제가 업로드한 그림에서의 메카니즘과

이 글에서 말하고자 하는 setsockopt를 이용한 버퍼를 zero로 하는 방법과

같은 의미인지 궁금합니다.

-----------
청하가 제안하는 소프트웨어 엔지니어로써 재미있게 사는 법
http://sozu.tistory.com

dudungsil의 이미지

글쓴이: dudungsil / 작성시간: 일, 2004/05/23 - 9:09오후

그림이 overlapped file i/o에 관한 것도 있네요. 그에 관한건 잘 모르겠습니다. winsock에서 유저버퍼를 바로 사용하는 것은 SO_RCVBUF를 0으로 셋팅하는 것 이외의 방법은 없다고 알고 있습니다.

회사에 있는 관계로 책이 없네요. 집에 가서 jeffrey의 programming application .. 시리즈와 solomon의 inside windows 2000을 후다닥 읽어보고 답변 드리도록 하겠습니다.

산넘어 산

dudungsil의 이미지

글쓴이: dudungsil / 작성시간: 일, 2004/05/23 - 9:44오후

http://support.microsoft.com/default.aspx?scid=kb;en-us;181611

맨 아래 보면 update:가 있네요. 제가 알고 있던 내용은 update위쪽까지만이네요. ㅠㅠ

말이 안된다고 생각했던게 어플리케이션에서 버퍼를 제공하지 않을경우에 소켓에 데이터가 도착하면 어찌될 것인가?라는 것때문이였는데, 이쪽은 좀 더 찾아봐야겠네요. 에혀...

산넘어 산

mach의 이미지

글쓴이: mach / 작성시간: 월, 2004/05/24 - 5:12오후

girneter wrote:
디바이스 내부 캐쉬에 있는건 MAC layer 패킷일테니
이걸 유저한테 넘겨줘봤자 패킷캡처 이외의 용도로는 쓸모가 없습니다.

유저 나름이겠습니다.
또한, 양방향성을 고려해야 할것입니다.

패킷 캡쳐말고, 이를 이용한 다른 기반기술의 예를 들어보면, http://www.cs.cornell.edu/Info/Projects/CAM/ 을 참고하시기 바랍니다.

"패킷캡쳐 이외의 용도로는 쓸모가 없습니다"라고 단정하시는 말씀은 너무 아쉽군요.

girneter wrote:

...
음식을 빨리 먹겠다고 날로 먹을 수는 없자나요? :D

불을 사용할 수 있다면 능히 익혀먹을 수 있을 것입니다.

------------------ P.S. --------------
지식은 오픈해서 검증받아야 산지식이된다고 동네 아저씨가 그러더라.

dudungsil의 이미지

글쓴이: dudungsil / 작성시간: 화, 2004/05/25 - 10:17오전

커널에서 관리하는 버퍼를 거치지 않고 직접 유저 버퍼에 데이터를 카피하는 방식이 더 효율적인가 하는 문제로 고심을 좀 했습니다만, 효과는 없을 것 같네요.

청하님이 올려주신 두장의 그림은 그다지 의미가 없다고 생각되어 집니다.

일단 소켓의 경우에 SO_RCVBUF를 0으로 만드는 방법이 얻는게 없다고 jones의 글에 나와 있고 파일의 경우 오히려 성능 저하의 요인이 된다고 생각합니다.

버퍼링을 하지 않는다는 말은 파일 I/O의 요청이 있을때마다 파일 읽기를 한다는 말인데 이건 캐쉬의 효과가 0이라는 말과 같습니다. 필요한 만큼 죽어라 읽어야 겠죠. 이것 말고도 또다른 걸림돌이 있습니다.

win32 CreateFile에 FILE_FLAG_NO_BUFFERING라는 플래그가 있습니다. 이 플래그를 사용하면 파일을 읽을때 반드시 sector size 크기의 배수로 파일을 읽어야 합니다. 이걸 뒤집어 생각해 보면 windows 커널이 sector size 크기를 기준으로 파일을 읽어 버퍼링하고 또 파일을 읽는 기준이 된다고 생각되어 집니다.

만일 위의 그림처럼 버퍼 카피 없이 직접 파일에서 읽어 들인다면 중간에 누군가 중재자가 있어야 한다는 말인것 같네요. Overlapped를 사용한다고 해서 이러한 제한을 모두 무시하고 독자적으로 작동을 할것 같지는 않습니다.

산넘어 산

sozu의 이미지

글쓴이: sozu / 작성시간: 화, 2004/05/25 - 10:49오전

와웅! 답변 감사합니다.

Quote:
말이 안된다고 생각했던게 어플리케이션에서 버퍼를 제공하지 않을경우에 소켓에 데이터가 도착하면 어찌될 것인가?라는 것때문이였는데,

일단 이경우에는 IOCP로 시스템을 구성했을때에는 기본적으로 항상

Recv 요청상태에 있게 됩니다. 즉, 서버가 시작되면서부터 Recv 요청을 무조건

하게 됩니다. 물론 Recv Completion이 일어나도 이어서 Recv 요청을 하게되죠

근데 저도 의문인게 Recv 요청을 하지 않는다면 날라오는 패킷들이 어떻게 처리되느냐 인데..

일단 제 생각에는 그럴때에는 Adaptive하게 OS에서 관리해 주지 않을까 라는 생각을 해봅니다.

즉, 무조건 버퍼링을 하지 않는것이 아니라 때에 따라서 OS의 개입이 달라질수

있다는 것입니다.

Quote:
만일 위의 그림처럼 버퍼 카피 없이 직접 파일에서 읽어 들인다면 중간에 누군가 중재자가 있어야 한다는 말인것 같네요. Overlapped를 사용한다고 해서 이러한 제한을 모두 무시하고 독자적으로 작동을 할것 같지는 않습니다.

이부분에 대해서는 저는 중재자가 있을수도 있다고 생각합니다. 성능을 위해서

추가적으로 필요한 리소스가 있다는것은 당연할수도 있습니다.

물론 여기서는 단정하기 힘든부분입니다.ㅜㅜ MS에서 내부구조를 공개한다면

좋겠지요 :evil:

기회가 되면 실험을 해보고 싶네요^-^

제가 괜히 IOCP얘기를 꺼내서;;;ㅠㅠ

-----------
청하가 제안하는 소프트웨어 엔지니어로써 재미있게 사는 법
http://sozu.tistory.com

urmajest의 이미지

글쓴이: urmajest / 작성시간: 화, 2004/05/25 - 3:17오후

궁금한 점이 있는데요..

커널에서 제공하는 버퍼(mbuf 같은것이겠죠?)를 거치지 않고 유저 버퍼로

복사를 한다는 게 어떻게 가능한지 이해가 가질 않네요..

예를 들어 UDP/IP/ETHERNET의 프로토콜 스택을 가정한다면,

패킷이 오면 ethernet header의 mac address가 자신의 것이거나

broadcasting이면 헤더 벗겨서 상위 레이어로 넘겨주고, 아니면 drop하겠죠

그 다음에 ip address로 마찬가지로 자신이 받거나 forward할 것인지 결정하고

그다음 udp header에서 포트 번호를 보고 어떤 유저 프로세스에게 데이터를

넘겨줄 것인지 결정하게 되는 것이자나요?

즉, src/dst ip address, src/dst portnumber를 통해 프로세스를 식별할

수가 있는 것인데 어떻게 커널 버퍼를 거치지 않을 수 있는걸까요..

^^

sangwoo의 이미지

글쓴이: sangwoo / 작성시간: 화, 2004/05/25 - 3:25오후

urmajest wrote:
궁금한 점이 있는데요..

커널에서 제공하는 버퍼(mbuf 같은것이겠죠?)를 거치지 않고 유저 버퍼로

복사를 한다는 게 어떻게 가능한지 이해가 가질 않네요..

예를 들어 UDP/IP/ETHERNET의 프로토콜 스택을 가정한다면,

패킷이 오면 ethernet header의 mac address가 자신의 것이거나

broadcasting이면 헤더 벗겨서 상위 레이어로 넘겨주고, 아니면 drop하겠죠

그 다음에 ip address로 마찬가지로 자신이 받거나 forward할 것인지 결정하고

그다음 udp header에서 포트 번호를 보고 어떤 유저 프로세스에게 데이터를

넘겨줄 것인지 결정하게 되는 것이자나요?

즉, src/dst ip address, src/dst portnumber를 통해 프로세스를 식별할

수가 있는 것인데 어떻게 커널 버퍼를 거치지 않을 수 있는걸까요..

^^

저도 확실히는 모릅니다만, 줏어들은 바에 의하면, zero-copy는 보통 소켓
레이어에서의 커널 버퍼와 유저랜드 vm사이의 copy 오버헤드를 없애 보려는
데 목적이 있는거 같습니다. mmap(2)과 비슷하다고 생각하시면 될까요?

http://www.cs.duke.edu/ari/trapeze/freenix/node6.html
참고가 될지도 모르겠네요.

----
Let's shut up and code.

urmajest의 이미지

글쓴이: urmajest / 작성시간: 화, 2004/05/25 - 3:36오후

위쪽에 sozu님이 링크하신 논문을 읽어보았더니(친근한 url -_-)

asynchronous UDP에서는 수신할 때에는 header부분만

커널 버퍼에 복사를 하는 것이더군요.

엄밀히 말하면 zero-copy라고 할 수는 없겠죠.

header size를 예측해야하는 문제도 있고,

header만 커널 버퍼에 복사해서 들여다봤더니,

'어라? 이거 icmp자나?' 그러면 다시 데이터 부분 커널로 읽어와야할테고,

"UDP에서는 좋고, 다른 경우라도 negative-effect는 없다." 가 아니라,

"UDP에서는 좋지만, 다른 경우라면 약간의 성능 저하가 따르기도한다."

인 것 같네요.

이 방법 이외에 zero-copy scheme이 있나요?

(수정) page-remapping이 있군요 -_-

alwaysN00b의 이미지

글쓴이: alwaysN00b / 작성시간: 수, 2004/05/26 - 12:57오전

sozu 님 링크하신 논문에서

1copy 더군요.

언제나 시작

cjy1126의 이미지

글쓴이: cjy1126 / 작성시간: 수, 2004/05/26 - 2:15오전

Pcap의 경우는 데이터를 중간에서 복사하는게 아닌가요?

Pcap프로그램을 띄우고 인터넷을 사용하면

Pcap프로세서와 인터넷 프로그램 둘다 패킷을 받습니다.

그리고 제 짧은 생각이지만, 커널이 아닌 유저로 바로 패킷을 보내면 오히려 오버헤드가 더 걸리지 않나요?

어차피 device는 커널과 연결된거니까, 결국은 커널에서 유저로 데이터를 보내주죠.(같은 영역을 공유하더라도...)

device에서 패킷을 받는건 커널에서 처리는 유저 영역에서 하기때문에 trap에 대한 오버헤드가 더 크지않나요?(trap이 오버헤드가 걸린다고 책에서 읽었습니다. 실제 어느정도인지는 잘모르겠습니다. 제 잘못된 추측인지도...)

또, 만약 그 패킷의 ip가 잘못된 아이피거나 손상된 헤더라면 커널을 통하면 커널에서 버렸을껄 trap을 감수하면서 유저모드로 처리하니까요.

제가 지식이 짧아서 솔직히 여기에 있는 글은 다 이해를 못하겠습니다만...

제가 이해한게 맞다면 커널을 통하는게 더 빠르다고 생각합니다.

제로카피가 이루어진다면 유저모드와 커널모드 전환의 trap과 잘못된 패킷이 왔을때가 좀 꺼림직하네요.

항상 제대로된 패킷만 온다면 trap의 문제점(다시 말하지만 trap의 오버헤드가 얼마나 심한지는 자신이 ㅡㅡ;)...만 해결하면 제로 카피가 더 좋을거란 생각도 드네요.

Pcap은 스티븐님의 네트웍 프로그램 20장대에 나왔습니다.

겜방 알바중이라서 책이 없네요.

그리고 디스크같은데서 데이터를 읽는것도 버퍼캐쉬를 거치는게 더 빠른걸로 알고있습니다.

bread(?) 알고리즘인가? 기억이 안나는데, 다음 데이터를 미리 읽는다고 하네요.

시스템콜로 1byte씩 읽는것보다 라이브러리콜을 쓰는게 trap이 적어서 더 좋다고 배웠거든요.

실제 라이브러리콜도 일정바이트 미리 읽고... 시스템콜도 버퍼캐쉬에 자주 사용되는것을 저장해두고, 다음에 읽을 데이터를 미리 읽는다고...

"유닉스의 내부구조 -조유근-"에서 읽은 기억이 있네요.

제가 글을 전체적으로 이해를 못해서 현문우답일수도 있습니다. ㅡ.ㅜ

만약 그렇다해도 몰라서 그려려니하고 이해해주세요. ㅡ.ㅜ

jinyeong의 이미지

글쓴이: jinyeong / 작성시간: 수, 2004/05/26 - 3:54오전

Quote:
그리고 제 짧은 생각이지만, 커널이 아닌 유저로 바로 패킷을 보내면 오히려 오버헤드가 더 걸리지 않나요?

어차피 device는 커널과 연결된거니까, 결국은 커널에서 유저로 데이터를 보내주죠.(같은 영역을 공유하더라도...)

device에서 패킷을 받는건 커널에서 처리는 유저 영역에서 하기때문에 trap에 대한 오버헤드가 더 크지않나요?(trap이 오버헤드가 걸린다고 책에서 읽었습니다. 실제 어느정도인지는 잘모르겠습니다. 제 잘못된 추측인지도...)

또, 만약 그 패킷의 ip가 잘못된 아이피거나 손상된 헤더라면 커널을 통하면 커널에서 버렸을껄 trap을 감수하면서 유저모드로 처리하니까요.

제가 지식이 짧아서 솔직히 여기에 있는 글은 다 이해를 못하겠습니다만...

제가 이해한게 맞다면 커널을 통하는게 더 빠르다고 생각합니다.

제로카피가 이루어진다면 유저모드와 커널모드 전환의 trap과 잘못된 패킷이 왔을때가 좀 꺼림직하네요.

항상 제대로된 패킷만 온다면 trap의 문제점(다시 말하지만 trap의 오버헤드가 얼마나 심한지는 자신이 ㅡㅡ;)...만 해결하면 제로 카피가 더 좋을거란 생각도 드네요.

zero-copy는 커널 mbuf와 user buf 사이에서의 메모리 copy를 없애려는 의미이지,
device layer에서 user로 바로 copy를 한다는 이야기가 아니지 않나요?
page mapping 등으로 real data의 copy를 없애겠다는 의미라고 봅니다.

그리고 제대로 된 패킷인지 아닌지는 user 영역이 아니라 모두 커널 영역에서 판단하게 됩니다.
그리고 kernel에서도 interface layer에서의 처리 이후에,
protocol layer로의 처리는 software interrupt에 의해 처리가 됩니다.
zero-copy와는 별로 관계가 없지 않을까요?

Quote:

그리고 디스크같은데서 데이터를 읽는것도 버퍼캐쉬를 거치는게 더 빠른걸로 알고있습니다.

bread(?) 알고리즘인가? 기억이 안나는데, 다음 데이터를 미리 읽는다고 하네요.

시스템콜로 1byte씩 읽는것보다 라이브러리콜을 쓰는게 trap이 적어서 더 좋다고 배웠거든요.

실제 라이브러리콜도 일정바이트 미리 읽고... 시스템콜도 버퍼캐쉬에 자주 사용되는것을 저장해두고, 다음에 읽을 데이터를 미리 읽는다고...

버퍼 캐쉬는 _다른 문제_입니다. 말씀 그대로 시스템 콜에서 1 byte씩
읽는 것 보다, user buffer를 거치는 것이 당연히 유리하겠지요.
이는 buffer cache 의 역할이 아니라 user library의 bufferring 때문입니다.

그리고 버퍼 캐쉬는 디스크 access 시 system call이든 library call이든
모두 사용하게 되는 것입니다. 물론 궁극적으로는 library call도 system call에 의해 사용되게 되는 것이겠지요.

I thought what I'd do was,
I'd pretend I was one of those deaf-mutes.. or should I?

cjy1126의 이미지

글쓴이: cjy1126 / 작성시간: 수, 2004/05/26 - 4:02오전

저는 sozu님의 overlapped I/O를 보고 그걸로 생각해서요.

아무래도 그림이 이해가 쉬워서, 글보다는 그림만 보게되네요.

그 그림보면 NDIS, TCP/IP를 안거치고 가길래요.

그리고 다른분들 답변도 패킷캡쳐 용도외에는 그런말이 있어서요.

윈도우 overlapped I/O가 zero-copy를 이용한게 아니였군요. ㅡ.ㅜ

혹시나 했는데... 역시나 실수네요.

제가 zero-copy에 대한 이해가 떨어져서 이상한글 남겨죄송합니다.

버퍼 캐쉬는 _다른 문제_입니다. 말씀 그대로 시스템 콜에서 1 byte씩 
읽는 것 보다, user buffer를 거치는 것이 당연히 유리하겠지요. 
이는 buffer cache 의 역할이 아니라 user library의 bufferring 때문입니다.

이부분은 제가 약간 글을 잘못쓴것 같네요.

user library의 시스템콜을 줄이기위한 bufferring같이 버퍼캐쉬도 bread(?) 알고리즘에 의해서 디스크 억세스 수를 줄인다는건데요.

즉... 제 결론은 커널이 웬만한건 알아서 잘해준다는... 그런뜻이였습니다.

댓글 달기

텍스트 포맷에 대한 자세한 정보

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.