Mentorship

My mentorship project, “Basic Azure Pipeline with Alpine and KNE,” focused on integrating SONiC-alpine dataplane testing into SONiC’s Azure Pipelines CI flow. SONiC utilizes Azure Pipelines, but current checks only validate the control plane. This projec made dataplane testing a first-class citizen by provisioning a VM in the pipeline, deploying Kubernetes Network Emulation (KNE) and SONiC-alpine, and then running automated dataplane test suites.

This work aims to:

• Improve test coverage beyond the control plane
• Catch dataplane regressions earlier.
• Provide a path for contributors to add tests and interpret results

In the longer term, it lays the groundwork for using Alpine-based dataplane tests as pre-submit gates across the SONiC ecosystem, thereby improving overall quality.

The integration of the VPP (Vector Packet Processing) dataplane with SONiC has traditionally  followed a monolithic model, where VPP runs as a tightly coupled process inside SONiC  containers. While this design works for a single virtual switch, it limits scalability and makes it  difficult to build large or distributed test environments. With the Alpine–Lucius pipeline and the  KNE (Kubernetes Network Emulation) cluster, there is now an opportunity to replace this  monolithic model with a more modern, containerized architecture.

This project aims to separate the VPP dataplane from the SONiC control plane, running VPP as  an independent Kubernetes pod inside the KNE environment while still being programmed by  SONiC. Using Kubernetes orchestration, the control plane can instantiate, configure, and  manage multiple VPP instances dynamically, enabling horizontal scaling and supporting more  complex topologies. This disaggregated architecture also improves flexibility—allowing  operators to isolate dataplane failures, allocate resources more efficiently, and manage VPP  and SONiC lifecycles independently—while still preserving the operational advantages of a  SONiC-based system.

The project I worked on was titled “Enhancing Redis Access Efficiency and Robustness in SONiC.” When we talk about Redis performance optimization in SONiC, there are usually three major areas to look at: optimizing the application code and how it interacts with Redis, improving the Redis client library itself or tuning the Redis server for the specific workload. In this project, my focus was on the first part, optimizing things from the application-code perspective and improving how the daemons talk to Redis.

The main idea of the project was to analyze how SONiC’s critical services and platform daemons interact with Redis, understand where unnecessary Redis traffic was coming from, and improve both the efficiency and stability of these interactions. This meant profiling the current Redis access patterns, setting up baseline load tests, and benchmarking behavior across different hardware platforms to see how Redis performed under varying workloads. Overall, the project aimed to reduce redundant operations, avoid long-latency interactions, and make sure the system remained responsive even under load.