fuchsia.hardware.network

Handle for the rx FIFO. Clients must write 16-bit descriptor indexes to this FIFO to be able to receive frames.

Handle for the tx FIFO. Clients write 16-bit descriptor indexes to this FIFO to enqueue outgoing frames.

The frame type this support entry refers to.

The frame type-specific features supported.

The flags supported for the given frame type.

Device's class, defined in DeviceClass.

Minimum descriptor length, in 64-bit words. Expresses the minimum length that each buffer descriptor must have for correct operation with this device. Devices that support extra frame metadata inform larger minimum descriptor lengths that reflect the minimum space needed to be able to store frame metadata.

Accepted descriptor version.

Maximum number of items in Rx FIFO (per session). rx_depth is calculated based on the size of the actual backing hardware rx queue.

Maximum number of items in Tx FIFO (per session). tx_depth is calculated based on the size of the actual backing hardware tx queue.

Alignment requirement for buffers in the data VMO. All buffers in the data VMO must be aligned to buffer_alignment relative to the start of the VMO.

Maximum supported length of buffers in the data VMO, in bytes.

The minimum RX buffer length for correct operation, in bytes.

The number of bytes the device requests be free as head space in a Tx buffer. Devices may choose to reject Tx buffers that do not satisfy this constraint.

The amount of bytes the device requests be free as tail space in a Tx buffer. Devices may choose to reject Tx buffers that to not satisfy this constraint.

Supported Rx frame types on this device.

Clients may open sessions subscribing to a subset of rx_types frame types on this device. Clients will only receive the frame types they are subscribed to in this session

Supported Tx frame types on this device.

A client is free to send any frame type on an open session, as long as the frame type is part of tx_types. Some network devices may need to perform partial frame parsing and serialization and, for that reason, tx_types is a vector of FrameTypeSupport which includes specific features per frame type.

For example, a device that supports Ethernet frames but needs to convert the Ethernet header may only support standard EthernetII frames, and not any "raw" Ethernet frame.

Available Rx acceleration flags for this device. rx_accel maps the RX_ACCEL_* flags in the frame descriptors with semantic acceleration features described by RxAcceleration. Position n of rx_accel conveys the meaning of the RX_ACCEL_n flag.

Available Tx acceleration flags for this device. tx_accel maps the TX_ACCEL_* flags in the frame descriptors with semantic acceleration features described by [fuchsia.hardware.network/TxAcceleration]. Position n of tx_accel conveys the meaning of the TX_ACCEL_n flag.

VMO containing the descriptors. 16-bit indices transmitted over the FIFOs index a descriptor in this VMO (byte offset = descriptor_length * 8 * index).

VMO containing frame data. Descriptors contain byte-offsets that are used to index arbitrary regions in data.

Requested descriptor version. If the network device does not support the requested descriptor version, Device.OpenSession will fail with ZX_ERR_NOT_SUPPORTED.

Descriptor length, in 64-bit words. The length of each descriptor in the descriptors VMO. This is used as a multiplier to find byte offsets in descriptors given a descriptor index passed through the Rx or Tx FIFOs.

Total number of descriptors that can be used by this session. Descriptor indices transferred through either the Rx or Tx FIFO must be in the range [0, descriptor_count).

Extra options.

List of frame types the client is subscribing to.

No extra information is available.

Device accepts only unicast frames addressed to its own unicast address, or multicast frames that are part of the multicast address filter list.

Device accepts unicast frames addressed to its own unicast address, or any multicast frames.

Device accepts all frames.

Inbound Rx frame validated the Ethernet Frame Check Sequence.

Inbound Rx frame validated the IPv4 checksum.

Inbound Rx frame validated the TCP checksum.

Inbound Rx frame validated the UDP checksum.

Request that device calculate the Ethernet Frame Check Sequence and write it in place.

Request that the device calculate the IPv4 checksum and write it in place.

Request that the device calculate the TCP checksum and write it in place.

Request that the device calculate the UDP checksum and write it in place.

Device status flags.

Maximum transmit unit for this device, in bytes. The reported MTU is the size of an ENTIRE frame, including any header and trailer bytes for whatever protocol the FrameTypes of this device support.

Device supports any type of ethernet frame. Same as specifying all other flags. Used by devices that do not inspect or parse outbound traffic.

Device supports EthernetII frames.

Device supports 802.1q VLAN additions.

Device supports 802.1 q-in-q Multiple VLAN tagging additions. Only meaningful if E_802_1_Q is also present.

Device supports 802.3 LLC + SNAP Ethernet frame format.

Acceleration flag 0. Acceleration flags are mapped to the acceleration features reported by the Device in Info.rx_accel. The n-th feature in rx_accel maps to the RX_ACCEL_n RxFlag.

Device experienced a hardware Rx overrun. Rx overruns are typically set by hardware controllers when a frame event was detected but the frame data couldn't be captured. Devices should clear the controller flag once this is set on an inbound frame, so future overruns can be detected and reported.

This bit is set if frame validation is performed (such as by hardware acceleration features) and fails. It's important to note that some devices may simply discard frames for which validation fails and never notify the client. Rx frames that failed validation are only transmitted to the client if the SessionFlags::REPORT_INVALID_RX option is selected when creating a session.

This is an echoed Tx frame, created by a Tx request. Can only be set in sessions that have the LISTEN_TX flag.

Sessions marked with the PRIMARY bit get the following different treatment:

• If no PRIMARY sessions are attached, the device will not serve Rx frames to non-PRIMARY sessions.
• If there's only one PRIMARY session active, it may get a zero-copy data path from the the backing hardware, if the underlying implementation supports it.

LISTEN_TX sessions will receive any outgoing frames (from all sessions) on its Rx path. Can be used for snooping traffic. Sessions marked with LISTEN_TX may also send frames, but they should keep in mind that they'll ALWAYS receive those frames back on their Rx path (no origin session filtering is performed).

Sessions marked with REPORT_INVALID_RX are interested in receiving frames that were rejected by internal device checks or payload validation performed by hardware. Due to the nature of some hardware platforms, sessions marked with REPORT_INVALID_RX may still not receive frames that fail validation if the hardware implementation simply drops the frame and doesn't expose it to the software stack. Sessions NOT marked with REPORT_INVALID_RX, in contrast, will NEVER receive an Rx frame with the RX_VALIDATION_ERROR flag set.

Device is online, i.e., data path is open and any ongoing sessions may send and receive frames.

Acceleration flag 0. Acceleration flags are mapped to the acceleration features reported by the Device in Info.tx_accel. The n-th feature in tx_accel maps to the TX_ACCEL_n TxFlag.

Requested operation in inbound_flags is not supported; the frame was not sent. Always set in conjunction with TX_RET_ERROR.

Could not allocate resources to send frame. Always set in conjunction with TX_RET_ERROR.

Device is not available (offline or disconnected); the frame was not sent. Always set in conjunction with TX_RET_ERROR.

Blanket definition for raw frames. Devices that do not perform any sort of parsing of outbound traffic should define FRAME_FEATURES_RAW in the FrameTypeSupport entry.

Maximum number of acceleration flags. Each descriptor has 16 bits of space for acceleration flags (RxFlags and TxFlags) thus the maximum number of reported accelerations is 16. Each descriptor reports which accelerations were applied (RxFlags) or are requested (TxFlags) by mapping indexes in the vector of supported accelerations (Info.rx_accel and (Info.tx_accel) to bits in the respective acceleration flags bitfield.

Maximum number of chained descriptors that describe a single frame.

Maximum numbers of supported frame types for Rx or Tx.

Maximum length of session label.

The maximum number of status samples that can be buffered by a StatusWatcher.