Programmable VNIC Pipeline Modification for Packet Processing

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Conventional packet processing in Software-Defined Networking (SDN) environments lacks efficiency and scalability, particularly in supporting specific types of receive-side scaling (RSS) functionalities, which are not easily upgradeable due to vendor delays and varied user demands, leading to complexity and overhead in software and hardware upgrades.

Innovation Solution

A programmable virtual network interface controller (VNIC) with a modifiable packet processing pipeline that allows injection of additional stages, such as enhanced RSS, to bypass or add functionality, enabling flexible and immediate support for specific networking requirements without requiring future releases.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If conventional packet processing is used in SDN environments, then hardware resources can be pooled and virtual machines can be supported, but packet processing efficiency and scalability are insufficient

Engineering Contradiction:

Improvepacket processing efficiencyVSAvoidscalability

Core Design Contradiction:

ProductivityVSAdaptability or versatility

Solution Approach 1:

The packet processing pipeline is made dynamically configurable through a modification interface that allows runtime injection, deletion, and reordering of processing stages. This dynamic architecture enables the system to adapt packet processing workflows to different networking requirements without hardware reconfiguration, simultaneously improving processing efficiency and scalability.

Inventive Principle:

Principle #15Dynamics

Solution Approach 2:

The packet processing pipeline is segmented into multiple independent processing stages that can be individually configured, injected, or deleted. Each stage handles specific packet processing tasks, allowing the system to optimize processing efficiency for different packet types while maintaining scalability through modular stage composition.

Inventive Principle:

Principle #1Segmentation

2Adaptability or versatility

If vendor-provided packet processing stages are used, then basic networking functionality is supported, but specific types of receive-side scaling functionalities cannot be easily upgraded due to vendor delays

Engineering Contradiction:

Improvefunctionality supportVSAvoidupgrade time

Core Design Contradiction:

Adaptability or versatilityVSLoss of time

Solution Approach 1:

The system enables self-service functionality injection by allowing users to directly inject custom packet processing stages through a modification interface without requiring vendor-provided updates. Users can immediately implement specific receive-side scaling functionalities by loading custom stage implementations, eliminating upgrade delays caused by vendor release cycles.

Inventive Principle:

Principle #25Self-service

Solution Approach 2:

The modification interface is pre-configured to accept and process stage injection requests, allowing users to prepare and deploy custom packet processing stages in advance. This preliminary capability enables immediate functionality upgrades without waiting for vendor releases, as the interface is already in place to accommodate custom stage implementations.

Inventive Principle:

Principle #10Preliminary action

3Adaptability or versatility

If the packet processing pipeline is modified to support new functionalities, then scalability and flexibility improve, but system complexity increases

Engineering Contradiction:

ImproveflexibilityVSAvoidpipeline complexity

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The modification interface serves multiple functions: injecting new stages, deleting existing stages, and reordering stages. This universal interface handles all pipeline modification operations through a single mechanism, reducing system complexity despite the ability to perform multiple modification types. The stage implementation follows a unified structure that can handle different packet processing tasks through consistent interfaces.

Inventive Principle:

Principle #6Universality (Multi-functionality)

4Ease of operation

If additional packet processing stages are injected, then specific networking requirements can be met immediately, but overhead in software and hardware upgrades increases

Engineering Contradiction:

Improvedeployment speedVSAvoidupgrade overhead

Core Design Contradiction:

Ease of operationVSDevice complexity

Solution Approach 1:

Custom packet processing stages are implemented as copyable modules that can be loaded and injected into the pipeline without modifying the core system. This copying mechanism allows rapid deployment of new functionalities by simply loading stage implementations, reducing upgrade overhead while enabling immediate meeting of specific networking requirements.

Inventive Principle:

Principle #26Copying

Data Source

PatentUS11736413B2Programmable virtual network interface controller (VNIC)

Publication Date: 2023.08.22 VMWARE INC

AI summary

Example methods and systems for a programmable virtual network interface controller (VNIC) to perform packet processing are described. In one example, the programmable VNIC may modify a packet processing pipeline based on the instruction. The modification may include injecting a second packet processing stage among the multiple first packet processing stages of the packet processing pipeline. In response to detecting an ingress packet that requires processing by the programmable VNIC, the ingress packet may be steered towards the modified packet processing pipeline. The ingress packet may then be processed using the modified packet processing pipeline by performing the second packet processing stage (a) to bypass at least one of the multiple first processing stages, or (b) in addition to the multiple first processing stages.