OSA Express driver, QDIO base support, HiperSockets
- Multicasting has to be switched on in the kernel
- The OSA Express Driver needs QDIO base support.
- Broadcast is not supported for OSA-Express with a LIC level
less than 3.0A
- Broadcast in conjunction with HiperSockets is not supported on
z800 and z900
- Broadcast for a z/VM guest LAN requires z/VM 4.4 service level
0401 or higher
- The MTU range is 576 - 61440. However, depending on the medium
and networking hardware settings, it may be restricted to 1492,
1500, 8992 or 9000. For HiperSockets the MTU range extends to
57344. This may be restricted by the framesize announced by the
- The maximum MTU size is limited by the maximum frame (buffer) size
supported by the hardware. The frame size for OSA-Express is fixed
at 64 KB. For HiperSockets, the maximum frame size is defined during
HiperSockets CHPID definition in the IOCDS. If the hardware
configuration specifies the maximum frame size as 40 KB, the MTU can
be configured up to 32 KB (frame size minus 8 KB) using ifconfig.
Possible frame sizes are 16, 24, 40, and 64 KB.
The total memory usage for inbound data buffers per device in
(number of buffers) * (Linux memory usage per buffer)
The number of buffers allocated by Linux can be specified for each
device via the sysfs attribute 'buffer_count';
the number of buffers must be between 8 and 128; the default is 16.
Linux memory usage per buffer is equivalent to the respective
- Layer 2 support requires IBM zSeries 990 or 890, or IBM System z9.
When running a Linux guest under VM, you need z/VM 5.1 with Layer 2
support in PTF for APAR VM63538 or later z/VM.
Networking - Layer 3 mode only
The following applies only when running in Layer 3 mode (i.e. not in Layer 2 mode):
- There may be circumstances that prevent ifconfig (or
other commands) from setting an IP address on an OSA-Express
network feature. The most common one is that another system in the
network has set that IP address already. As a result, the IP
address will be indicated by ifconfig as being set on the
interface, but the address is not actually set on the feature.
Since the design of the network stack in Linux does not allow
feedback about IP address changes, there is no means of notifying
the user of the problem other than to log a message. This message
(usually containing text such as "could not set IP address" or
"duplicate IP address") will appear in the kernel messages
(displayable using "dmesg"). For most distribution settings, this
will also trigger a message in /var/log/messages. If you are not
sure whether the IP address was set properly or experience a
networking problem, you should always check these logs to see if an
error was encountered when setting the address.
This requirement applies to both IPv4 and IPv6 addresses, and to IP
takeover, VIPA, HiperSockets, and Proxy ARP.
- On OSA-Express querying the ARP cache (qetharp -q) only returns
a maximum of 62 entries, even though more entries might exist in a
device's ARP cache.
Networking - Layer 2 mode only
The following applies only when running in Layer 2 mode:
- When exploiting Layer 2 support with a Linux system that is not
connected to a z/VM VSwitch, the user must manually configure a unique
MAC address (which must be different from the default MAC address of the port) for the Linux interface.
- See also below "Networking - Layer 2 / Layer 3 traffic".
Networking - Layer 2 / Layer 3 traffic
The following restriction on Layer 2 and Layer 3 traffic applies
only when running in Layer 2 mode on IBM zSeries 990 or 890 or earlier IBM System z9:
- Two hosts that need to communicate with each other and that share the
same CHPID (port sharing) can only communicate when using the same transport
mode - either Layer 2 with Layer 2 or Layer 3 with Layer 3. Layer 2 and
Layer 3 traffic can be transmitted over the same OSA CHPID, but not
between two hosts sharing the same CHPID.
The above restriction does not apply when running on recent IBM System z9 - see:
- "Remove L2/L3 LPAR-to-LPAR Restriction" on Networking Enhancements for IBM System z
- section "OSA Layer 2/Layer 3 transport enhancement" in:
- IBM U.S. Software Hardware Announcement Letter 106-287
"IBM System z9 Business Class - z9 top technology innovation for small and medium enterprises"
- IBM U.S. Software Hardware Announcement Letter 106-293 "IBM System z9 Enterprise Class: A security-rich, resilient and scalable mainframe for managing on demand infrastructures"
sizes may fail due to "order-N allocation failed" problem
using MTU sizes >8K on a network interface, the Linux TCP/IP
stack may run into problems on heavily loaded systems because
allocating memory for packets may fail due to memory fragmentation.
As a symptom of this problem you will see messages of the form
"order-N allocation failed" in the system log; in addition, network
connections will drop packets, in extreme cases to the extent that
the network is no longer usable.
As a workaround, use MTU sizes at
most of 8K (minus header size), even if the network hardware allows
larger sizes (e.g. HiperSockets, gigabit ethernet).
Back to top