Editing Networking/NIC Software
Jump to navigation
Jump to search
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.
| Latest revision | Your text | ||
| Line 4: | Line 4: | ||
:Welcome to the [https://www.opencompute.org/projects/networking OCP Networking] '''NIC Software''' subproject. | :Welcome to the [https://www.opencompute.org/projects/networking OCP Networking] '''NIC Software''' subproject. | ||
Our goal is to bring together NIC vendors and hyperscaler and other users to spur discussion about relevant NIC features, and | Our goal is to bring together NIC vendors and hyperscaler and other users to spur discussion about relevant NIC features, and define unambiguous, concrete specifications for the API and behavior of each feature. | ||
With this, we aim to ensure that all vendor implementations support the actual business requirements of large users. These requirements have historically often been underspecified or shared only with individual vendors (possibly under NDA). Open communication ensures that all vendors can compete, and users have choice. | |||
For each feature, after reaching consensus | For each feature, after reaching consensus we publish a specification that covers both driver API and behavior: metrics and threshold values. We will share concrete conformance tests that vendors can use to self-certify. | ||
===Charter=== | ===Charter=== | ||
| Line 14: | Line 14: | ||
The focus is on traditional NIC networking features. | The focus is on traditional NIC networking features. | ||
Significant developments are taking place in SmartNICs. | Significant developments are taking place in SmartNICs. For now, features not strictly related to the core network transmit and receive path are out of scope. This includes on-board co-processors operating systems, control plane offload and offload of non networking interfaces, such as NVME (storage). | ||
===Public=== | ===Public=== | ||
| Line 54: | Line 54: | ||
Standardize state-of-the-art TE mechanisms. | Standardize state-of-the-art TE mechanisms. | ||
Develop common support for stateless [https://www.kernel.org/doc/html/latest/networking/segmentation-offloads.html#generic-segmentation-offload generic tunneling offload] | Develop common support for stateless [https://www.kernel.org/doc/html/latest/networking/segmentation-offloads.html#generic-segmentation-offload generic tunneling offload]: combine TCP segmentation offload (an indispensible offload for many workloads) with arbitrary tunnel protocols, instead of building an offload for each tunnel protocol. Because hyperscalers may use protocols, protocol stacks and protocol variants --proprietary or not-- that the vendor cannot always anticipate. | ||
Develop industry standard support for [https://legacy.netdevconf.info/0x12/session.html?evolving-from-afap-teaching-nics-about-time Earliest Departure Time] (EDT) stateless rate limiting offload. | Develop industry standard support for [https://legacy.netdevconf.info/0x12/session.html?evolving-from-afap-teaching-nics-about-time Earliest Departure Time] (EDT) stateless rate limiting offload. | ||
===Flow Steering=== | ===Flow Steering=== | ||
Device queues are the basis for scalable networking | Device queues are the basis for scalable networking, as well as task isolation and userspace queues. | ||
Define | Define | ||
# a common interface for configuring devices queues and RSS groups, including | # a common interface for configuring devices queues and RSS groups, including dynamically without device down. | ||
# a common interface for steering flows to queue (groups), including expectations on datapath performance and scalability | # a common interface for steering flows to queue (groups), including expectations on datapath performance and scalability. | ||
Additionally, define | Additionally, define | ||
| Line 74: | Line 74: | ||
Hardware support for offload of these and other protocols is uneven. | Hardware support for offload of these and other protocols is uneven. | ||
Define key requirements, such as support for specific cryptographic algorithms like ChaCha2020-Poly1305, specific protocols such as QUIC and resulting | Define key requirements, such as support for specific cryptographic algorithms like ChaCha2020-Poly1305, specific protocols such as QUIC and resulting requiremnts, such as framing and stream re-synchronization. | ||
Current protocols under active work are | Current protocols under active work are | ||
| Line 83: | Line 83: | ||
Expand hardware capabilities from PTP to include high-rate, high-precision timestamps on every packet. Both Rx and Tx. | Expand hardware capabilities from PTP to include high-rate, high-precision timestamps on every packet. Both Rx and Tx. | ||
Accurate time measurement is essential to advanced congestion control (e.g., [https://dl.acm.org/doi/pdf/10.1145/3387514.3406591 Swift] | Accurate time measurement is essential to advanced congestion control (e.g., [https://dl.acm.org/doi/pdf/10.1145/3387514.3406591 Swift] and fleetwide health measurement and even applications such as a globally distributed database ([https://research.google/pubs/pub39966/ Spanner]), among potentially others. | ||
==Get Involved== | ==Get Involved== | ||