1. Frame Preemption functional description

Frame preemption is defined in IEEE 802.1Qbu and 802.3br and allows low priority frames to be suspended by time-critical frames of higher priority.

Frame preemption is not yet supported via standard Linux user commands but the community is working to include support for frame preemption in ethtool.

Until then a proprietary tool called fp is provided:

# fp --help
options:
--dev:                    dev name
--admin_status:           admin status
--enable_tx:              enable tx
--verify_disable_tx:      verify disable tx
--verify_time:            verify time
--add_frag_size:          add frag size
--status:                 status
--help:                   help

The parameters are:

  • dev <DEV> - The device, e.g. eth0.

  • admin_status <BITMASK> - Bitmask of priority queues where frame preemption is enabled, e.g. 0x02 enables priority queue 1.

  • enable_tx <0 | 1> - Enable frame preemption in the transmitter. Frame preemption is always enabled in the receiver.

  • verify_disable_tx <0 | 1> - Disable verification of preemption capabilities of the link if 1. Default is 1 (disabled).

  • verify_time <TIME> - Number of milliseconds to wait between verification attempts. The valid range is 1..128 and the default is 10.

  • add_frag_size <FRAG_SIZE> - The minimum fragment size to generate in the transmitter, calculated as (FRAG_SIZE + 1) * 64 octets. The valid range is 0..3 and the default is 0.

  • status - Show frame preemption status.

  • help - Show frame preemption help.

Show current configuration:

# fp --dev eth0
admin_status: 0x0
enable_tx: 0
verify_disable_tx: 1
verify_time: 10
add_frag_size: 0

The parameters are explained above.

Show current status:

# fp --dev eth0 --status
dev: eth0
hold_advance: 42
release_advance: 84
preemption_active: 0
hold_request: 0
status_verify: Disabled

The parameters are:

  • dev <DEV> - The device, e.g. eth0.

  • hold_advance <TIME> - The maximum number of nanoseconds from issuing a HOLD request from 802.1Qbv until the traffic stops. Currently not supported.

  • release_advance <TIME> - The maximum number of nanoseconds from issuing a RELEASE request from 802.1Qbv until the traffic resumes. Currently not supported.

  • preemption_active <0 | 1> - 1 if frame preemption is currently active on device.

  • hold_request <0 | 1> - 1 if HOLD request is currently active on interface.

  • status_verify <Initial | Idle | Send | Wait | Succeeded | Failed | Disabled> - Status of the verification process.

Enable frame preemption and verification on eth0:

# fp --dev eth0 --enable_tx 1 --verify_disable_tx 0

Enable frame preemption for priority queues 0, 1, and 2 on eth0:

# fp --dev eth0 --admin_status 0x07

Some test tools expect to receive LLDP information regarding frame preemption before they attempt to enable their own frame preemption capabilities.

A modified version of tiny-lldpd is included in the BSP that is able to transmit an LLDP frame containing the Additional Ethernet capabilities documented in IEEE 802.3br-2016.

Start the tiny-lldpd daemon in the background:

# tlldpd
Starting tiny-lldpd...

The LLDP/TLV contains the following values:

  • preemption capability support - Always 1 (supported).

  • preemption capability status - 1 if frame preemption is enabled on device, 0 otherwise.

  • preemption capability active - 1 if frame preemption is active on device, 0 otherwise.

  • additional fragment size - Always 0 as 64 octet fragments are supported by the receiver.

The tiny-lldpd daemon uses the following read-only files in debugfs to query the parameters (eth0 is used in the example):

  • /sys/kernel/debug/lan966x/eth0/fp-enabled

  • /sys/kernel/debug/lan966x/eth0/fp-active

These files returns either 0 or 1 when read and can be used if you want to write your own LLDP implementation.