NIC Driver Runtime Configuration via DSL Emulation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Device driver redesign is time-consuming and inefficient when network interface controller (NIC) capabilities change, as it requires modifications to access and utilize new or shifted operations, leading to potential inability to access NIC operations.

Innovation Solution

A driver that can flexibly configure a NIC hardware parser to support processing operations without modification by learning hardware capabilities at runtime and translating Domain Specific Language (DSL) instructions into hardware command representations, allowing for exception path handling by processors when necessary.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If device driver is redesigned to access new or modified NIC operations, then access to NIC capabilities is maintained, but development time and complexity increase

Engineering Contradiction:
ImproveAccess to NIC capabilitiesVSAvoidDriver redesign time
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The device driver dynamically determines the configuration of the packet processing pipeline based on runtime hardware capabilities rather than requiring static redesign. The driver learns hardware capabilities at runtime and adapts its operation accordingly, allowing it to work with different NIC configurations without modification.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The system changes the operational parameters of the driver by introducing a learning mechanism that discovers hardware capabilities dynamically. Instead of hardcoding driver behavior for specific hardware versions, the driver adjusts its parameters and configuration based on what it learns about the actual hardware capabilities during runtime.

Inventive Principle:
Principle #35Parameter changes

2Adaptability or versatility

If operations are shifted to processors or accelerators, then processing flexibility improves, but driver complexity increases

Engineering Contradiction:
ImproveProcessing flexibilityVSAvoidDriver design complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

A learning mechanism acts as an intermediary between the device driver and the hardware capabilities. This intermediary layer discovers and translates hardware capabilities into driver-configurable parameters, simplifying the driver design while maintaining flexibility to utilize processors or accelerators when needed.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The driver performs preliminary learning actions to discover hardware capabilities before actual packet processing begins. By pre-configuring the packet processing pipeline based on learned capabilities, the driver avoids complex runtime decisions and simplifies the overall design.

Inventive Principle:
Principle #10Preliminary action

3Adaptability or versatility

If driver is modified to support new NIC capabilities, then functionality is updated, but reliability of existing operations may decrease

Engineering Contradiction:
ImproveSupport for new capabilitiesVSAvoidExisting operations stability
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The device driver performs self-configuration by automatically learning hardware capabilities at runtime. This self-service approach ensures that the driver adapts to the actual hardware present, maintaining reliability of existing operations while automatically supporting new capabilities without manual modification or testing.

Inventive Principle:
Principle #25Self-service

Data Source

PatentUS20230091195A1Flow offloading method for a programmable network interface controller (NIC)
Publication Date: 2023.03.23 INTEL CORP
  • US20230091195A1 patent drawing
  • US20230091195A1 patent drawing
  • US20230091195A1 patent drawing

AI summary

Examples described herein relate to a driver that is to: determine a configuration of a packet processing pipeline of a network interface device to perform an instruction set written in a domain specific language (DSL) for the packet processing pipeline based on emulation or analysis of a parser of the packet processing pipeline and provide the configuration to the packet processing pipeline of the network interface device to specify operations of the packet processing pipeline of the network interface device.