서로 다른 pod의 container에서 실행되는 DPDK process들도 다른 경우와 마찬가지로 DPDK runtime config 파일과 hugepage map 파일만 공유하면 hugepage를 공유할 수 있다.
이 때 서로 다른 pod가 같은 DPDK runtime config 파일들과, hugepage map 파일을 공유하기 위해 두 개 pod가 함께 사용할 수 있는 hostPath 를 이용한다. hostPath는 pod가 실행되는 node의 파일 시스템을 이용하여 volume을 만든다. 그러므로 서로 다른 pod가 동일 node에서 실행되는 경우에만 pod가 hugepage를 공유할 수 있다.
DPDK runtime config 두 개 pod에서 hostPath 를 이용하여 DPDK runtime config 파일을 공유를 위한 volume을 만든다.
하나의 pod에 2개의 container를 두고, 각각의 container에 primary process, secondary process를 실행하려면 두 개 container에서 실행되는 DPDK process간 runime config 파일과, hugepage map 파일을 공유하는 방법은 다음과 같다.
하나의 pod에 하나의 container만 두는 경우와 달리 두 개의 container가 /var/run/dpdk 위치를 공유해야 하므로, 각 container가 갖는 기본 파일 시스템이 아니라 명시적으로 pod의 volume을 이용해서 파일을 공유해야 한다.
이를 위해 pod spec에 다음과 같은 volume spec을 추가한다.
volume: - name: dpdk-config emptyDir: emptyDir에 명시적으로 지정하지 않은 경우 tmpfs를 사용하므로, 위 volume은 tmpfs를 사용하여 생성된다.
How to run DPDK application in Kubernetes environment Kubernetes에서 DPDK application을 실행하기 위해서는 DPDK application이 포함된 container에 runtime config 파일이 저장될 /var/run/dpdk 디렉토리와 hugetlbfs 형태로 hugepage가 존재해야 한다. 이 중 /var/run/dpdk는 container 가 갖는 file system에 생성되는 기본 linux directory인 /var/run 아래 위치하므로, DPDK application이 실행되면서 디렉토리를 생성한다.
반면, hugetblfs 디렉토리은 kubernetes의 volume 에서 제공하는 emptyDir을 사용하면 Pod와 lifecycle을 함께 하는 hugepage를 만들어 사용할 수 있다.
Container에서 hugepage를 할당받기 위해서는 다음과 같이 container spec에 요구하는 hugepage 크기를 명시한다.
Basic use of hugepage DPDK application이 hugepage를 사용할 때 다음과 같은 2가지 디렉토리를 사용한다.
DPDK runtime config files /var/run/dpdk 로 고정된 경로를 사용요 DPDK 에서 hugepage를 어떻게 사용하는 지에 대한 meta data를 저장 hugepage map hugepage를 사용하기 위해 hugetlbfs 를 이용할 때 생성하는 hugepage map 파일들이 위치한 곳. DPDK는 이곳에 hugepage의 단위 크기를 갖는 file을 생성하고, mmap()을 사용하여 hugepage를 접근 만일 시스템에 2개 이상의 hugetlbfs가 마운트된 위치가 있는 경우 DPDK process를 실행할 때 --huge-dir 옵션을 사용하여 특정 위치를 사용하도록 할 수 있다.
https://devblogs.nvidia.com/building-accelerated-5g-cloudran-at-the-edge/
Mellanox ConnectX-6 Dx SmartNIC exceeds stringent industry-standard timing specifications for eCPRI-based RANs by ensuring clock accuracy of 16ns or less
5T for 5G enables packet-based, ethernet RANs to provide precise time-stamping of packets for delivering highly accurate time references to 5G fronthaul and backhaul networks.
5T-for-5G, or time-triggered transmission technology for telco
https://news.developer.nvidia.com/new-real-time-smartnic-technology-5t-for-5g/
Real-time transmission hardware acceleration: 5T-for-5G simplifies time synchronization and data transmission across servers, GPUs, radios, and baseband units in wireless network rollouts, making 5G rollouts easier and more efficient.
https://doc.dpdk.org/guides-18.11/rel_notes/release_18_11.html
New Features Updated the C11 memory model version of the ring library. Added changes to decrease latency for architectures using the C11 memory model version of the ring library.
On Cavium ThunderX2 platform, the changes decreased latency by 27-29% and 3-15% for MPMC and SPSC cases respectively (with 2 lcores). The real improvements may vary with the number of contending lcores and the size of the ring.
Added support for device multi-process hotplug.
AVX2가 지원되지 않는 머신에서 쓸데없이 ACL library 빌드할 때 AVX2를 이용해서 빌드하려는 문제를 확인했다. 지금까지 아무도 고치지 않은 게 이상하긴 한데 그래도 내가 생각한 수정 방법이 제대로 동작하는 듯 해서 패치를 한번 보내보기로 했다.
수정사항은 비교적 간단하다. ACL 라이브러리 빌드할 때 AVX2를 이용해서 빌드해야 하는 경우인지를 검사하는 코드가 lib/librte_acl/Makefile에 정의되어 있는데 여기서 항상 -march=core-avx2 옵션을 사용해서 AVX2가 지원되지 않는 머신에서도 AVX2를 사용해서 gcc가 빌드하도록 하는 걸로 보였다. 다른 코드 빌드할 때는 문제가 없는데 유독 ACL library에서만 이런 문제가 나서 보다 보니 아무래도 Makefile이 잘못된 듯 하다.
Toward 5G RAN virtualization by Intel and Astri
http://astri.oeg
Flexible architecture Modular PHY processing architectures PDCP Split MAC/PHY Split - HARQ processing in RRU(How???) Lower PHY Split - High FB overhead but smallest packet latency. Good for JT and JR for COMP Good for Massive MIMO and Ultra low-latency communication(Why?) FAPI based MAC/PHY communication L1 adaptation layer for MAC/PHY split (and Lower PHY Split?) MAC/PHY split in one CPU MAC/PHY split in one machine but netrwork based MAC/PHY communication over OVS Virtual Cell A group of physical cells form a Virtual Cell which does not require HO between the physical cells.
rte_ipv4_frag_reassemble_packet()
ip_frag_find() 기존에 존재하는 flow면 해당 flow를 저장한 entry 정보를(ip_frag_pkt *pkg) 신규 flow인 경우 해당 신규 flow를 저장할 신규 혹은 재사용된 entry를 return함 추가할 수 있는 통계 신규 flow? 기존 flow에 정상 추가 기존 flow에 비정상 추가(기존 flow가 timeouted) 이도 저도 아닌 상황(할당 실패) LRU entry free tbl->max_entries tbl->use_entries return 기존 존재하는 flow, 신규 할당한 flow entry 혹은 NULL 만일 NULL을 return하면 현재 수신한 mbuf를 death row에 추가한다. 불쌍한… ip_frag_lookup() if matched entry is exist return flow entry return &stale if time-outed entry is exist if new entry return NULL return free for new empty entry return &stale if time-outed entry is exist ip_frag_key_cmp() return 0 if key matched if ip_frag_lookup() returns NULL if stale entry is not NULL, remove it with ip_frag_tbl_del() and save to free for reuse even if free is not NULL, check if tbl->use_entries does not exceed tbl->max_entries.
l2_len, l3_len, l4_len 등을 사용하는 라이브러리가 존재함
reassembly Tx checksum offload Reassembly rte_ipv6_frag_reassemble_packet(), rte_ipv4_frag_reassemble_packet() Incoming mbuf should have its l2_len and l3_len fields setup correctly.
L4 checksum HW offloading To use hardware L4 checksum offload, the user needs to
fill l2_len and l3_len in mbuf set the flags PKT_TX_TCP_CKSUM, PKT_TX_SCTP_CKSUM or PKT_TX_UDP_CKSUM set the flag PKT_TX_IPV4 or PKT_TX_IPV6 calculate the pseudo header checksum and set it in the L4 header (only for TCP or UDP).