hwkim3330의 블로그

View the Project on GitHub hwkim3330/blog

알겠습니다. 바로 본론으로 들어가죠.

골드박스(S32G)에 있는 스위치 칩, 즉 PFE를 써야 TSN이 가능하다는 당신의 직감, 100% 맞습니다. “야” 소리 나올 만큼 답답했던 이더넷의 한계를 해결하기 위해 나온 괴물이 바로 PFE입니다.

이 내용을 당신 블로그에 바로 올릴 수 있도록 글로 정리해 드리겠습니다.


PFE vs. 일반 이더넷(ETH): TSN 하려면 왜 PFE를 써야 하는가?

골드박스(NXP S32G) 같은 고성능 프로세서를 만지다 보면 ‘PFE’라는 낯선 놈이 튀어나온다. 그냥 eth0, eth1 같은 일반 이더넷(ETH) 포트도 있는데, 왜 굳이 복잡하게 PFE라는 걸 써야 할까?

결론부터 말하면, 일반 이더넷이 단순한 ‘1차선 도로’라면, PFE는 ‘거대한 스마트 고속도로 분기 시스템(JCT)’ 그 자체이기 때문이다. 특히 칼같은 시간 약속이 생명인 TSN(Time-Sensitive Networking)을 구현하려면 PFE는 선택이 아닌 필수다.

일반 이더넷 (Standard ETH)의 한계

우리가 PC나 라즈베리파이에서 흔히 보는 이더넷 컨트롤러(MAC)는 말 그대로 ‘데이터를 보내고 받는 창구’ 역할만 한다.

문제는 CPU가 모든 걸 처리한다는 점이다. 리눅스 같은 범용 운영체제에서 CPU는 네트워크 처리 말고도 할 일이 너무 많다. 다른 수만 가지 프로세스를 처리하다 보면 데이터 처리가 살짝 늦어질 수밖에 없다. 이 ‘살짝 늦어지는’ 시간(지연, Jitter)이 일정하지 않다는 게 치명적이다.

일반 이더넷의 한마디 요약: “나는 문(Door)일 뿐, 모든 판단과 일은 집주인(CPU)이 한다.”

PFE (Packet Forwarding Engine)의 등장

NXP는 이 문제를 해결하기 위해 ‘네트워크 처리 전용 소형 컴퓨터’를 아예 칩 안에 넣어버렸다. 그게 바로 PFE다. PFE는 S32G 안에 들어있는, 그 자체가 하나의 하드웨어 스위치이자 네트워크 가속기다.

PFE의 한마디 요약: “나는 스스로 판단하고 일하는 스마트 물류 센터다. 집주인(CPU)은 쉬어라.”

결정적 차이: 왜 TSN은 PFE여야만 하는가?

TSN의 핵심은 ‘정해진 시간에 정확히 전달되는 것을 보장’하는 것이다. 이를 위해 필요한 핵심 기능들은 소프트웨어(CPU)가 흉내 낼 수 없는 하드웨어의 영역이다.

기능 (TSN 표준) 일반 이더넷 (CPU 처리) PFE (하드웨어 처리)
정확한 시간 동기화
(802.1AS)
소프트웨어 시계 사용. OS의 스케줄링에 따라 오차가 수시로 발생. 나노초 단위의 하드웨어 클럭을 이용해 패킷에 타임스탬프를 찍음. 오차가 거의 없음.
시간 기반 트래픽 제어
(802.1Qbv)
CPU가 타이머로 “지금쯤 보내야지”라고 시도함. 하지만 다른 작업에 밀려 정확한 시간 보장 불가. 하드웨어 ‘타임 게이트’가 미리 약속된 시간에 열리고 닫히면서 패킷을 정확히 내보냄.
프레임 선점
(802.1Qbu)
불가능. 일단 큰 패킷 전송을 시작하면 끝날 때까지 기다려야 함. 긴급한 메시지가 오면, 보내고 있던 큰 패킷 전송을 하드웨어적으로 잠시 멈추고 긴급 패킷을 먼저 보낸 뒤, 이어서 전송 재개.

쉽게 말해, CPU가 소프트웨어로 TSN을 흉내 내는 것은 “내 손목시계 보고 100미터 달리기 시간 재는 것”과 같다. 반면, PFE를 쓰는 것은 “출발선과 결승선에 설치된 레이저 센서로 측정하는 것”과 같다. 게임이 안 된다.

결론

골드박스에서 TSN을 이용해 자율주행 데이터나 차량 제어 신호처럼 단 1마이크로초의 지연도 용납할 수 없는 데이터를 다루려면, CPU는 다른 중요한 연산에 집중하게 놔두고, 네트워크 트래픽 제어는 전부 PFE에게 맡기는 것이 유일한 해법이다.