English version below

IBM z17 hat eine umfassende Transformation durchlaufen und verfügt nun über eine vollständig neue I/O-Hardware-Logik für Storage und Netzwerk, bei der die I/O-Funktion direkt in den Z-Prozessor als DPU (Data Processing Unit) integriert ist. Dadurch rücken Prozessor und Speicher näher an die I/O-Funktionen, was Z-Workloads ein effizienteres Wachstum und eine bessere Skalierbarkeit ermöglicht. IBM Z-Kunden profitieren somit direkt von erhöhter I/O-Kapazität und Skalierbarkeit der Network-Express-Funktion.

IBM Z unterstützt mehrere Netzwerkprotokolle über Ethernet, doch jedes Protokoll benötigt eigene physische Ressourcen, was die Netzwerkkonfiguration erschweren und den Hardwarebedarf erhöhen kann — zum Beispiel mehrere I/O-Kartensteckplätze, Switch-Kabel, Switch-Ports und mehr. Um die Netzwerkkonfiguration effizienter und einfacher zu gestalten, wurde der Network Express Adapter entwickelt.

VORTEILE DES NETWORK EXPRESS ADAPTERS AUF z17

• Zukunftssichere Hardware: Verbesserte I/O-Kapazität, höhere Skalierbarkeit und gesteigerte Dichte dank der Network-Express-Funktion.
• RoCE ohne Zusatzinvestitionen: RDMA über Converged Ethernet (RoCE) kann genutzt werden, ohne zusätzliche Kosten.
• Vereinfachte Konfiguration: Reduzierung der Komplexität bei HCD- und z/OS-Einstellungen.
• VTAM-frei für IP-Kommunikation: Keine aufwendige VTAM-Konfiguration notwendig, um IP-Verbindungen zu nutzen.
• Unterstützung der automatischen Migration von IPAQENET/IPAQENET6 zu EQENET/EQENET6.

Beeindruckend, oder? Schauen wir uns nun die neue Karte genauer an, um diese Vorteile besser zu verstehen.

CONVERGED MULTI-FUNCTION NETWORK ADAPTER 

NEUE NETZWERKKARTE

Der Network-Express-Adapter bietet „converged“ Unterstützung für mehrere Netzwerkprotokolle und dient als gemeinsame Hardware des IBM z17 für OSA, RoCE und Coupling Express3 Long Reach (CE-LR). Er fasst den bisherigen OSA-Express, RoCE-Express und CE-LR in einer einzigen Hardwareplattform zusammen.

• Unterstützt Long-Reach- (LR) und Short-Reach- (SR) Verbindungen
• Übertragungsgeschwindigkeiten: 10 Gbit/s (FC 0525) und 25 Gbit/s (FC 0526)
• Kompatibel mit Singlemode-Faser (LR/LX) & Multimode-Faser (SR/SX)
• Network Express verhandelt nicht automatisch auf eine niedrigere Geschwindigkeit.

CONVERGED MULTI-FUNCTION NETWORK ADAPTER 

ZENTRALE KONZEPTE UND TERMINOLOGIE

Bei der Verwendung des Network-Express-Adapters kommt ein neuer CHPID-Typ für OSA zum Einsatz — OSH, basierend auf der Enhanced-QDIO (EQDIO)-Architektur — sowie ein neuer FID-Typ für RoCE — NETH.

Der Adapter verfügt über zwei Ports, von denen jeder gleichzeitig zwei „Persönlichkeiten“ unterstützen kann: OSH und NETH. Dadurch bietet der Adapter sowohl OSA- als auch RoCE-Funktionalität auf demselben Port einer einzelnen Karte. Für einige RoCE-Nutzer entfällt somit die Notwendigkeit, eine separate OSA-Karte ausschließlich zur Aktivierung von RoCE-I/O bereitzustellen.

Ein physischer Port des Adapters kann je nach Bedarf so konfiguriert werden, dass er ausschließlich OSH, ausschließlich NETH oder beide Modi gleichzeitig unterstützt.

ENHANCED QDIO (EQDIO)

EQDIO ist die nächste Generation der Systemarchitektur und ersetzt das traditionelle QDIO (Queued Direct I/O), das von OSA-Express-Adaptern verwendet wird.

Einige wichtige Unterschiede von EQDIO:

• Jede EQDIO-Schnittstelle benötigt nun nur noch eine Device-Nummer
• OSD Read/Write Devices werden durch Control Queues ersetzt, die sowohl das Senden als auch Empfangen von Paketen ermöglichen
• Es gibt einen neuen z/OS INTERFACE Statement-Typ EQENET
• EQDIO unterstützt ausschließlich den Layer-2-Modus (Ethernet). Eine Layer-3-Unterstützung (IP) wie bei QDIO ist nicht verfügbar.
• Der vom Benutzer in z/OS definierte VTAM TRLE entfällt. Sobald die EQENET-Schnittstelle online geht, erstellt VTAM automatisch das TRLE.

🔍 Mehr erfahren? 👉 Washington System Center

VOGELPERSPEKTIVE: OSA-EXPRESS VS. NETWORK EXPRESS

• Network Express Adapter unterstützt alle bisherigen Funktionen, die mit OSA OSD verfügbar sind, verwendet jedoch die EQDIO- (Enhanced-QDIO-) Architektur und den CHPID-Typ OSH für OSA-ähnliche I/O-Funktionen.
• Die Karte hat zwei Ports, jeweils einem PCHID zugeordnet, sodass die Port-Angabe in Kanal- oder Software-Definitionen entfällt.
• Beide Ports müssen die gleiche Art von Geschwindigkeit und Optik haben. Ports mit unterschiedlichen Geschwindigkeiten oder Optiken können nicht gemischt werden.
• Die PCHIDs auf der Karte werden vom neuen On-Chip-DPU-Prozessor verwaltet, es sei denn, sie sind im IOCDS für den Physical Function (PF) Access Mode als NETD* definiert. In diesem Fall wird die PF einer Kundenpartition zugewiesen, statt vom DPU verwaltet zu werden.

*NETD bietet native Unterstützung von Linux auf IBM Z für alle TCP/IP- und RDMA-Protokolle. Es steht auf der eingeschränkten Liste für GA1.

VOGELPERSPEKTIVE: ROCE-EXPRESS VS. NETWORK EXPRESS

• Bei Network Express Adapter heißen die RoCE-PFIDs jetzt NETH.
• In der klassischen RoCE/ROC2-Welt mussten die PFIDs in Resource Groups eingetragen werden, was bei neuen Network Express Adapter entfällt. Stattdessen übernimmt die OSA-Firmware die Verwaltung der physischen Funktionen (PF).
• Die Network-Express-Karte wird als OSA-Karte betrachtet, obwohl sie RoCE-I/O ausführen kann, da sie im Gegensatz zu RoCE-Adaptern keiner Resource Group (PSP) zugeordnet ist.
• Network Express bietet die gleichen Virtualisierungsfunktionen wie RoCE Express3, RoCE Express2.1 und 2.0.
• Für z/OS CS bleibt die SMC-R-Konfiguration unverändert.

z/OS OSH (EQENET) AUTO-MIGRATION CAPABILITY

z/OS CommServer bietet eine Migrationsfunktion namens OSH Auto-Migration. Diese Funktion ermöglicht es dem Benutzer, seine vorhandene IPAQENET-INTERFACE-Definition weiterhin zu nutzen. Sie passt eine bestehende IPAQENET-OSD-INTERFACE-Definition automatisch an (migriert sie zu) eine EQENET-OSH-INTERFACE-Definition an.

Um die Auto-Migrate-Funktion für eine bestehende IPAQENET-INTERFACE-Definition nutzen zu können, fügen Sie zu IPAQENET Folgendes hinzu:

• DEVNUM-Parameter eines der mit der CU verbundenen Geräte
• IPADDR mit Subnetzmaske (IPv4), falls noch nicht definiert
• VMAC, falls noch nicht definiert (wenn nicht vorhanden, wird sie beim Start von TCP/IP dynamisch erzeugt)

NETZWERKSTRATEGIE

Wie bestimmt man, wie viele Network Express-Ports bestellt werden sollen? - Man sollte mindestens so viele Ports bestellen, wie zur Abdeckung der aktuellen Anzahl an OSA-Ports sowie der aktuellen Anzahl an RoCE-Ports erforderlich sind.

Englisch Version

Imagine a network that is flexible and completely hassle-free – with no extra hardware or complex configurations. The new Network Express Adapter on the IBM z17 makes this possible: more performance with less complexity. Welcome to the next generation of networking!

IBM z17 has undergone a transformation with an entirely new System I/O hardware and architecture model for both storage and networking. IBM z17 offers I/O capability that is integrated directly within the Z processor complex as a DPU (Data Processing Unit). The new system design moves processor and memory closer to I/O capability transforming I/O operations allowing Z workloads to grow and scale to meet the growing transactional needs of current and future workloads.

IBM Z supports multiple network protocols over Ethernet, but each protocol requires its own physical resources, which can complicate network configuration and increase hardware demands — for example, additional I/O card slots, switch cables, switch ports, and more. To make network configuration more efficient and easier to manage, the Network Express Adapter was developed.

ADVANTAGES OF THE NETWORK EXPRESS ADAPTER ON z17

• Future-proof hardware: IBM Z customers will benefit from the increased I/O capacity, scale and density of the Network Express feature.
• RoCE without additional investment: RDMA over Converged Ethernet (RoCE) can be leveraged without extra costs.
• Simplified configuration: Reduced complexity in HCD and z/OS settings.
• The z/OS user defined VTAM TRLE is eliminated!  A dynamic TRLE is created for each EQENET INTERFACE.
• Auto-migration from IPAQENET/IPAQENET6 to EQENET/EQENET6 supported.

Impressive, isn’t it? Let’s take a closer look at the new card to better understand these benefits.

CONVERGED MULTI-FUNCTION NETWORK ADAPTER

NEW NETWORK CARD

The Network Express Adapter provides Converged support for multiple networking protocols and serves as a common hardware adapter for OSA, RoCE, and Coupling Express3 Long Reach (CE-LR). It consolidates the former OSA-Express, RoCE-Express, and CE-LR functions into a single hardware platform.

• Supports Long-Reach (LR) and Short-Reach (SR) connections
• Transmission speeds: 10 G (FC 0525) and 25 G (FC 0526)
• Compatible with single-mode fiber (LR/LX) and multi-mode fiber (SR/SX)
• Networking Express does NOT auto-negotiate to a slower speed

CONVERGED MULTI-FUNCTION NETWORK ADAPTER

KEY CONCEPTS AND TERMINOLOGY

When using the Network Express Adapter, a new CHPID type for OSA — OSH, based on the Enhanced-QDIO (EQDIO) architecture — is introduced, along with a new FID type for RoCE—NETH.

The adapter has two ports, each of which can simultaneously support two “personalities”: OSH and NETH. This allows the adapter to provide both OSA and RoCE functionality on the same port of a single card. This eliminates the need for some users of RoCE to buy a dedicated OSA card just to enable RoCE I/O.

A physical port on the adapter can be configured as needed to support OSH only, NETH only, or both modes at the same time.

ENHANCED QDIO (EQDIO)

QDIO is the next generation of system architecture, replacing the traditional QDIO (Queued Direct I/O) used by OSA-Express adapters.
Key differences introduced with EQDIO include:

• Each OSA interface is defined with a single OSH device number. 
• Control read/write devices are replaced with control queues, which handle both sending and receiving of packets.
• A new z/OS INTERFACE statement type, EQENET, is introduced.
• EQDIO supports Layer 2 (Ethernet) only. Layer 3 (IP) support, as provided by QDIO, is not available.
• The z/OS user defined VTAM TRLE is eliminated!  A dynamic TRLE is created for each EQENET INTERFACE.

🔍 Want to learn more? 👉 Washington System Center

HELICOPTER VIEW: OSA-EXPRESS VS. NETWORK EXPRESS

• The Network Express Adapter supports all functions previously available with OSA OSD, but uses the EQDIO (Enhanced-QDIO) architecture and the OSH CHPID type for OSA-like I/O operations.
• The card includes two ports, each associated with a PCHID, eliminating the need to specify a port number in channel or software definitions.
• Both PCHIDs must use the same speed and optics type. Mixing different speeds or optics on the same card is not supported.
• The PCHIDs on the card are managed by the new on-chip DPU processor, unless they are defined as NETD* in the IOCDS for Physical Function (PF) Access Mode, where the PF is assigned to a customer partition instead of DPU.

*NETD provides native Linux on IBM Z support for all TCP/IP and RDMA protocols. It is on the restricted list for GA1.

HELICOPTER VIEW: ROCE-EXPRESS VS. NETWORK EXPRESS 

• With the Network Express Adapter, the RoCE PFIDs are now called NETH.
• In the traditional RoCE/ROC2 environment, PFIDs had to be defined in Resource Groups. With the new Network Express Adapter, this is no longer required—the OSA firmware now manages the physical functions (PF) automatically.
• The Network Express card is considered an OSA card even though it can perform RoCE I/O because it is not associated with a Resource Group (PSP) unlike RoCE adapters.
• Network Express has the same virtualization capabilities as RoCE Express3, RoCE Express2.1 and 2.0.
• For z/OS Communications Server, the SMC-R configuration remains unchanged.

z/OS OSH (EQENET) AUTO-MIGRATION CAPABILITY

z/OS CommServer provides a migration capability called OSH Auto-Migration. 
This function allows a user to continue using their existing IPAQENET INTERFACE definition. It automatically adapts (migrates) an existing IPAQENET OSD INTERFACE definition to EQENET OSH INTERFACE definition.

To enable the auto-migration function for an existing IPAQENET INTERFACE definition, you must add the following to IPAQENET:

• The DEVNUM parameter of one of the devices attached to the CU
• IPADDR with subnet mask (IPv4), if not already defined
• VMAC, if not already defined (if omitted, it will be generated dynamically at TCP/IP startup)

NETWORK STRATEGY

How to determine how many Network Express ports to order? - Order at least the number of ports equal to the greather of current number of OSA ports and current number of RoCE ports.