Hội nghị Quốc gia lần thứ 24 về Điện tử, Truyền thông và Công nghệ Thông tin (REV-ECIT2021)
Hướng tiếp cận DPDK trong tối ưu hiệu năng
xử lý gói tin trên hệ thống gNodeB 5G
Tăng Thiên Vũ*, Nguyễn Văn Thành, Nguyễn Chí Kiên, Lý Nguyễn Hồng Phúc, Phạm Xn Trà, Bùi
Việt Hùng, Vũ Tuấn Đức
Dự án trạm thu phát sóng 5G,
Dự án 5G gNodeB - Tổng công ty Công nghiệp Công nghệ cao Viettel
Email:
(Control Plane) và Mặt phẳng người dùng UP (User Plane).
Mặt phẳng UP yêu cầu rất cao về tốc độ xử lý và lưu lượng
gói tin, trong đó mặt phẳng CP yêu cầu nhiêu hơn về độ
phức tạp của các giao thức báo hiệu.
Tóm tắt — Để đáp ứng được yêu cầu ngày càng cao về lưu
lượng dữ liệu người dùng, sự tăng nhanh về số lượng người
dùng và đa dạng các loại hình dịch vụ, hệ thống mạng di động
thế hệ thứ 5 (5G) gặp phải giới hạn ở bài tốn xử lý số lượng
gói tin lớn ở tốc đô cao. Các phương án tiếp cận truyền thống
cho thấy các nhược điểm về băng thông thấp cũng như tải cao
tại các lõi xử lý CPU. Ở bài báo này chúng tôi giới thiệu một
hướng tiếp cận mới, trong đó nền tảng Data Plane
Development KIT (DPDK) được sử dụng kết hợp với phương
pháp xử lý gói tin truyền thống để giải quyết vấn đề tồn tại về
tải xử lý cao và giới hạn băng thông trong mạng truy nhập của
hệ thống 5G.
Xử lý gói tin trong theo phương pháp truyền thống trong
hệ thống 5G gNodeB sử dụng các kỹ thuật gửi nhận Socket
API (Application Programming Interface). Socket API với
nền tảng là Linux Kernel Network Stack cung cấp một tập
hợp rất nhiều các giao thức mạng, hỗ trợ hiệu quả cho giao
diện CP. Cũng chính vì việc hỗ trợ nhiều giao thức ở nhiều
tầng (stack) cộng thêm sử dụng cơ chế truyền thông ngắt
(interrupt-driven) dẫn đến đối với mặt phẳng UP, cách tiếp
cận sử dụng socket này lộ rõ điểm yếu về tốc độ xử lý gói
tin cũng như tải xử lý của bộ xử lý trung tâm CPU
(Central Processing Unit). DPDK không hoạt động giống
với một network stack, việc giữ cho quá trình xử lý đơn giản
kết hợp với áp dụng các kỹ thuật như Poll Mode Driver và
quản lý bộ nhớ theo dạng Huge-page giúp DPDK xử lý gói
tin hiệu quả hơn so với phương pháp Socket API.
Keywords- DPDK, xử lý gói tin, trạm thu phát sóng 5G, NGRAN, gNodeB.
I.
GIỚI THIỆU
Kiến trúc mạng di động thế hệ thứ 5 (5G) được chia
thành ba thành phần chính như trong Hình 1, gồm: Mạng lõi
(Core Network), Mạng truyền dẫn (Transportation
Network) và Mạng truy cập (Radio Access Network –
RAN) [2]. Mạng 5G hỗ trợ ba loại dịch vụ cơ bản, đó là:
enhanced Mobile Broadband (eMBB), massive Machine
Type Communications (mMTC) và Ultra-Reliable and Low
Latency Communications (URLLC). Để đáp ứng được
những yêu cầu của các loại dịch vụ này, chuẩn 5G định
nghĩa về giao diện thế hệ mới cho Mạng truy nhập RAN,
gọi là NG - Next Generation RAN. Trạm thu phát sóng 5G
sử dụng thiết kết NG-RAN được gọi là gNodeB.
gNodeB được cấu thành từ ba thành phần chính như
trong Hình 2, gồm: CU (Central Unit), DU (Distributed
Unit) và RU (Radio Unit). Trong đó kết nối giữa gNodeB
và Mạng truyền dẫn là kết nối backhaul, cung cấp kết nối
giữa CU và Mạng lõi. Kết nối giữa CU và các DU được gọi
là midhaul, kết nối DU và RU là fronthaul.
Hình 2. Kết nối của các khối bên trong 5G-RAN
Trong bài báo này, chúng tôi sẽ mô tả cách tiếp cận mới,
trong đó sử dụng kết hợp cơng nghệ DPDK và Socket API
để giải quyết vấn đề giới hạn về băng thông xử lý của mặt
phẳng UP trong gNodeB. Phần còn lại của bài báo được tổ
thành ba phần lớn. Phần II cung cấp thông tin về cách tiếp
cận hiện tại, mô tả về hướng tiếp cận mới sử dụng DPDK
cho các kết nối backhaul và midhaul. Phần III là tổng hợp
các kết quả thử nghiệm kỹ thuật DPDK trong hệ thống 5G
mà chúng tôi đã đạt được. Cuối cùng, phần kết luận bài báo
được thể hiện trong mục IV.
II.
A. Cách tiếp cận truyền thống – Socket API cho gNodeB
Hình 3 mơ tả kiến trúc của giao diện backhaul và
midhaul trên trong gNodeB. Trong đó ở đường backhaul,
Hình 1. Mơ hình mạng di động thế hệ thứ 5 - 5G
Các kết nối backhaul, midhaul và fronthaul được chia
thành các mặt phẳng, gồm: Mặt phẳng điều khiển CP
ISBN 978-604-80-5958-3
DPDK TRONG XỬ LÝ GÓI TIN TRONG 5G GNODEB
226
Hội nghị Quốc gia lần thứ 24 về Điện tử, Truyền thông và Công nghệ Thông tin (REV-ECIT2021)
các cổng socket được mở để truyền nhận dữ liệu tuyến lên
(uplink) và tuyến xuống (downlink). Tương tự ở đường
midhaul, các cổng socket được mở trên giao diện lo loopback (một giao diện mạng đặc biệt trong hệ điều hành
Linux, trong đó các gói tin khi gửi vào giao diện này, thay
vì gửi ra cơng mạng, gói tin được gửi ngược lại cho hệ điều
hành).
tiếp nhận được dữ liệu. Chi tiết hơn về kiến trúc của DPDK
có thể tìm thấy tại [6].
Ở cơ chế socket-based, gói tin truyền và nhận dựa trên
cơ chế sự kiện ngắt (interrupt). Ngay các các kỹ thuật nâng
cấp liên quan đến xử lý ngắt như NAPI [3] cũng không đáp
ứng được yêu cầu ngày càng tăng về băng thông của các
giao diện mạng. Để khắc phục được điểm yếu của cách tiếp
cận socket, DPDK sử dụng PMD (Poll Mode Driver). Đối
với PMD, thay vì chờ ngắt thơng báo sự kiện gói tin đến,
PMD sẽ tiến hành đọc liên tục các gói tin tại cổng mạng.
Với cách tiếp cận này toàn bộ dữ liệu của CP và UP tại
kết nối backhaul và midhaul đều cần phải đi qua Linux
Network Stack. Nhược điểm của phương án này là xuất hiện
các điểm giới hạn băng thông do socket không phù hợp cho
truyền nhận lượng dữ liệu lớn trên mặt phẳng UP.
Về phần bộ nhớ, để dữ liệu có thể được gửi từ phần cứng
lên không gian người dùng một cách hiệu quả, DPDK sử
dụng thêm một kỹ thuật quản lý bộ nhớ nâng cao của Linux,
gọi là huge-page. Thông thường Linux quản lý bộ nhớ chính
bằng phương pháp phân tách bộ nhớ thành các vùng địa chỉ
vật lý liên tục với dung lượng 4 KB, gọi là page. Việc các
page được chia thành 4K khiến độ phân mảnh bộ nhớ cao
và dẫn đến hiệu năng của quá trình DMA - Direct Memory
Access thấp. Linux cung cấp thêm cơ chế quản lý các page
lớn hơn 4K, gọi là các huge-page. DPDK tận dụng cơ chế
huge-page này để tăng hiệu năng của quá trình truyền nhận
gói tin giữa phần mềm và phần cứng.
Hình 3. Kết nối Backhaul và Midhaul sử dụng socket
Phần tiếp theo của bài báo sẽ mô tả cách mà DPDK được
áp dụng vào hệ thống 5G gNodeB để giải quyết vấn đề liên
quan đến tốc độ xử lý gói tin và tải xử lý cao của phương
pháp Socket API.
B. Kết nối backhaul sử dụng công nghệ DPDK
DPDK - Data Plane Development KIT được Intel lần
đầu giới thiệu vào năm 2010. Mã nguồn mở này là tập hợp
các thư viện và bộ cơng cụ sử dụng cho xử lý gói tin hiệu
quả trên nền tảng kiến trúc chip Intel [1], góp phần khai sinh
ra một hướng tiếp cận hoàn toàn mới cho q trình xử lý gói
tin trong các hệ thống máy tính. Những điểm đặc biệt trong
kiến trúc dẫn đến hiệu năng đáng kinh ngạc của DPDK là:
kernel-bypass (bỏ qua xử lý gói tin tại kernel), kỹ thuật
polling trong xử lý ngắt và quản lý bộ nhớ dưới dạng hugepage.
Hình 5. Sử dụng DPDK cho kết nối backhaul
Hình 5 mơ tả vị trí mà DPDK được áp dụng tại kết nối
backhaul, thay vì ứng dụng CU gửi và nhận gói tin cho
mạng lõi thông qua các API (Application Programming
Interface) socket thì CU sẽ gửi và nhận gói tin thơng qua các
API của DPDK. Sự hiệu quả của việc áp dụng DPDK cho
kết nối backhaul sẽ được thể hiện trong phần III của bài báo
này.
Ngồi ra, bản thân DPDK khơng phải là một chồng giao
thức mạng (network stack) [4], do đó nhược điểm của q
trình sử dụng DPDK là khơng thể hỗ trợ đủ được các giao
thức phức tạp của mặt phẳng CP CU. Để giải quyết vấn đề
này, một kỹ thuật của DPDK khác được thêm vào ở giao
diện backhaul DPDK, và được trình bày ở phần tiếp theo.
C. Sử dụng kỹ thuật DPDK KNI cho mặt phẳng CP ở kết
nối backhaul
Trong phần trước, DPDK được sử dụng để thay thế
socket cho giao diện backhaul giải quyết được hạn chế về
tốc độ xử lý gói tin và tải xử lý cho mặt phẳng UP. Để có
thể đáp ứng được yêu cầu về độ phức tạp của các giao thức
trên mặt phẳng CP, kỹ thuật KNI (Kernel Network
Interface) của DPDK được áp dụng.
Hình 4. Các yếu tố khiến DPDK khác biệt so với Linux
Netwwork Stack
Hình 4 mơ tả các thành phần trong hệ thống DPDK [5],
có thể nhận thấy được thay vì gói tin được truyền qua Linux
Kernel network stack, gói tin được gửi thẳng lên không gian
người dùng (user space), nơi mà các ứng dụng có thể trực
ISBN 978-604-80-5958-3
Ý tưởng của KNI là biến một cổng mạng đã được dùng
cho DPDK có thể hỗ trợ thêm được API Socket. Để thực
227
Hội nghị Quốc gia lần thứ 24 về Điện tử, Truyền thông và Công nghệ Thông tin (REV-ECIT2021)
hiện được ý tưởng này, dữ liệu tại tầng ứng dụng của DPDK
sau khi nhận từ NIC được gửi và nhận đến một khối chức
năng trong nhân Linux do cộng đồng DPDK phát triển
(rte_kni.ko), khối chức năng này đăng ký với Linux một
giao diện Ethernet ảo. Dữ liệu gói tin DPDK thơng qua giao
diện ảo này được gửivào Linux Kernel Stack, qua đó người
dùng có thể dùng socket API cho một cổng mạng đã được
dùng cho DPDK.
Trong phần này sẽ mô tả phương án sử dụng kết hợp
DPDK và Linux Stack cho giao diện midhaul. Trong đó mặt
phẳng CP của midhaul sẽ tiếp tục sử dụng socket trên cổng
lo, trong khi mặt phẳng UP sẽ sử dụng nền tảng DPDK
Ring-buffer. Hình 7 mơ tả kiến trúc của giao diện midhaul
khi sử dụng phối hợp hai kỹ thuật này.
III.
Như vậy, với một cổng mạng có chạy DPDK, kỹ thuật
KNI hỗ trợ API socket cho mặt phẳng CP. Để có thể hỗ trợ
được cho cả mặt phẳng UP, một bộ lọc gói tin được thiết kế
trong đó: gói tin ở măt phẳng CP được giữ nguyên và gửi
lại cho khối KNI, gói tin ở mặt phẳng UP được gửi trực tiếp
cho ng dụng. Hình 6 mô tả thiết kế của giao diện backhaul
khi sử dụng DPDK và kỹ thuật KNI kết hợp lọc gói tin.
Hình 8 mơ tả kiến trúc chung cho tồn bộ hệ thống kết
nối trên của mặt phẳng CP và UP trên gNodeB sử dụng
DPDK. Trong hình vẽ này, tồn bộ các kỹ thuật được mô tả
ở các phần trước được áp dụng, gồm: DPDK KNI tại
backhaul, DPDK Ring buffer tại midhaul.
Hình 8. Kiến trúc đầy đủ của các kết nối backhaul và
midhaul trong 5G-RAN.
Kiến trúc này đã được thử nghiệm trên hệ thống 5G do
dự án 5G thuộc Tổng công ty CN CNC Viettel thực hiện.
Kết quả đo đạc của các giao diện được thể hiện ở trong các
thống kê dưới đây được thực hiện trên hệ thống sử dụng chip
Intel Xeon Gold, bộ nhớ 128GB, NIC Intel X710 Fortville
và chạy hệ điều hành CentOS7. Phiên bản của DPDK cho
thử nghiệm này là 19.11.2.
Hình 6. Sử dụng kỹ thuật DPDK KNI cho kết nối backhaul
D. Áp dụng kỹ thuật DPDK Ring-buffer cho giao diện
midhaul
Như đã nhắc đến ở phần trước, trong cách tiếp cần
truyền thống, ngoài việc áp dụng socket cho kết nối ở
backhaul, kết nối midhaul giữa CU và DU cũng sử dụng các
API socket. Khác với kết nối backhaul, kết nối midhaul sử
dụng API socket trên giao diện lo (loopback) của Linux.
Đặc điểm của giao diện này là không kết nối đến phần cứng
công mạng (NIC, Network Interface Card), việc không kết
nối đến phần cứng này dẫn đến băng thông của socket ở
cổng loopback sẽ cao hơn nhiều so với cổng mạng thật ở
giao diện backhaul. Mặc dù gói tin không cần gửi/nhận từ
phần cứng nhưng vẫn sẽ cần đi qua Linux Kernel Network
Stack. Đối với mặt phẳng UP, lượng dữ liệu truyền rất lớn
dẫn đến khi đi qua Kernel Stack sẽ gây tải cao cho các khối
xử lý trung tâm (CPU).
Bài thử nghiệm thực hiện với băng thông 1.8Gpbs của
toàn hệ thống, tải xử lý của các CPU tại kết nối backhaul
(Hình 9) và kết nối midhaul (Hình 10) được đo với các kịch
bản kích thước gói tin khác nhau.
Hình 9 thể hiện tải xử lý của luồng nhận dữ liệu tại kết
nối backhaul. Nhận thấy, cùng một băng thông là 1.8Gbps,
hệ thống sử dụng Socket API cần tải CPU nhiều hơn so
với trường hợp sử dụng DPDK.
Hình 9. So sánh tải của luồng (thread) chương trình nhận
gói tin tại kết nối backhaul
Tương tự tại kết nối midhaul, cũng cùng điều kiện là
băng thông thử nghiệm 1.8Gbps, tải CPU sử dụng cho nhận
gói tin tại DU khi chạy Socket API cao hơn rất nhiều khi sử
dụng DPDK.
Hình 7. Sử dụng DPDK ring buffer cho kết nối midhaul
ISBN 978-604-80-5958-3
GIẢI PHÁP TOÀN DIỆN CHO MẶT PHẲNG CU VÀ RU
TRONG 5G GNODEB
228
Hội nghị Quốc gia lần thứ 24 về Điện tử, Truyền thơng và Cơng nghệ Thơng tin (REV-ECIT2021)
Ngồi ra, kết quả thử nghiệm cũng cho thấy rằng, tải xử
lý của hệ thống sử dụng Socket API phụ thuộc nhiều vào
kích thước gói tin. Cùng một băng thơng, xử lý gói tin có
kích thước bé tốn nhiều tải CPU hơn so với gói tin có kích
thước lớn. Vấn đề này khơng gặp phải khi sử dụng DPDK.
Bản thân công nghệ DPDK cũng là một nhánh của các
công nghệ giảm tải (offloading), trong tương lai khơng xa,
để có thể phá vỡ thêm nhiều giới hạn cho 5G cũng như các
thế hệ mạng di động tiếp theo, hướng tiếp cận offloading,
đặc biệt là hardware offloading cần được nghiêm túc đánh
giá và thử nghiệm.
Trong bài báo này, phương án sử dụng DPDK RingBuffer giải quyết được các vấn đề về băng thông cho mặt
phẳng UP giữa CU và DU. Song song đó, phương án này
vẫn cịn có nhược điểm khi các khối logic CU và DU phải
được triển khai trên một máy tính vật lý, nhược điểm này sẽ
hạn chế độ linh hoạt của các phương án triển khai và cần
phải được cân nhắc nâng cấp trong các nghiên cứu tiếp
theo..
TÀI LIỆU THAM KHẢO
[1]
Hình 10. So sánh tải của luồng (thread) chương trình
nhận gói tin tại kết nối backhaul
[2]
[3]
IV.
KẾT LUẬN
Với sự phát triển mạnh mẽ của mạng di động, đặc biệt
mạng di động thế hệ thứ 5, các phương pháp tiếp cận truyền
thống bắt đầu xuất hiện các giới hạn, việc ứng dụng các kỹ
thuật xử lý gói tin mới như DPDK góp phần phá vỡ các giới
hạn đó.
[4]
Bài báo đã mơ tả các kết quả của việc áp dụng DPDK
cho hệ thống 5G gNodeB trên các giao diện backhaul và
midhaul. Bài báo cũng mơ tả các kỹ thuật để có thể phối hợp
hoạt động giữa phương pháp DPDK và phương pháp truyền
thống. Sự kết hợp này giúp tận dụng được các điểm mạnh
khác nhau của từng phương án.
[6]
ISBN 978-604-80-5958-3
[5]
229
Xiaoban Wu, Peilong Li, Yongyi Ran, Yan Luo. “Network
measurement for 100 GbE network links using multicore
processors[J]”. Future Generation Computer Systems, 2017.
3GPP 5G, “5G; NG-RAN; Architecture description,” ETSI TS 138
401 V15.2.0, July. 2018.
Kai Zhu, Xíngshu Chen, Jun Tang, “A Method of Adaptive
Selection of Hybrid Interrupt-NAPI Scheme”, ICCIIS, 2010.
Cerrato I, Annarumma M, Risso F. Supporting Fine-Grained
Network Functions through Intel DPDK[C].Third European
Workshop on Soft ware Defined Networks. IEEE Computer Society,
2014:1-6.
Bi H, Wang Z H. DPDK-based Improvement of Packet
Forwarding[J]. 2016, 7:01009.
W. R. Intel, High-performance multi-core networking software
design options, White Paper 2011.