Hard Processor System Technical Reference Manual: Agilex™ 5 SoCs

ID 814346
Date 11/27/2024
Public
Document Table of Contents

5.1.6.10.2. Frame Preemption

Overview of the Frame Preemption

The IEEE 802.1Qbv-2015 defines the schedule for each of the queues on every egress port which makes the implementation aware of traffic arrival schedule. This information can be used to block the lower priority traffic from transmission in this time window/slot. This ensures that scheduled traffic is forwarded from sender to receiver through all the network nodes with a deterministic delay.

One of the important requirements to achieve a low latency is to ensure there are no interfering frames during the scheduled windows that are reserved for high priority traffic. The use of scheduled traffic imposes limitations while starting a transmission.

If an interfering frame begins transmission just before the start of a reserved time period, it can extend transmission into the reserved window, and potentially interfere with higher priority traffic. Therefore, a guard band whose size is equal to the largest possible interfering frame is required before the window starts.

A larger guard band equates to a less efficient use of network bandwidth. However, with the implementation of IEEE802.1Qbu (frame preemption), this issue is addressed. Frame preemption breaks the interfering frame into smaller fragments. Therefore, the guard band needs to be only as large as the largest possible interfering fragment instead of the largest possible interfering frame.

During the guard band, only the frames that can complete the transmission of the entire frame before the next gate close event are permitted. This ensures that the high priority traffic can always start at the beginning of the window reserved for it.

Description of the Frame Preemption

Frame Preemption (FPE) allows one or more higher priority (express) frames to interrupt the transmission of a lower priority (preemptable) frame; the preemptable frame transmission resumes and completes after the express frame transmission is complete. To support frame preemption, the MAC has the following two abstractions:
  • A preemptable MAC, called pMAC, which carries the preemptable traffic.
  • An express MAC, called eMAC, which carries the express traffic.

In the implementation, only parts of the MAC that holds the state during preemption is replicated and represented as pMAC and eMAC. The MAC uses the following two ways to puts on hold, the transmission of the preemptable traffic, in the presence of express traffic:

  • The MTL scheduler interrupts the preemptable traffic that is currently being transmitted. When the preemption capability is active, the MAC interrupts the transmission and reception of preemptable frames. A preempted fragment can be followed by zero or more express frames, before the continuation fragments. The preemptable frame can be fragmented any number of times, however, the minimum final and non-final fragment length criterion must be met. However, interleaving of more than 1 preemptable packet is not permitted. This implies that if a preemptable packet is fragmented by an express packet, another preemptable packet cannot be transferred until all the remaining fragments of the first preempted packet are transferred.
  • The MTL scheduler prevents starting the transmission of preemptable traffic. When the preemption capability is inactive, the pMAC entity is disabled and only express traffic is transmitted or received.

Enabling the Frame Preemption

Enable the frame preemption feature by setting EFPE field of the MAC_FPE_CTRL_STS register.

GCL Modification to Support Frame Preemption

In the EST-only configuration, the GCL entry has up to 24 bits of time interval and up to 8 high order bits representing the gate open/close state requirements as shown in following table.
Table 168.  Gate Control List When FPE is Disabled
Gate Control (up to 8 bits) Time Interval (ns) 16, 20 or 24 bits
OOCCCCCC T0
OOOOCCCC T1
CCCCOOCC T2
CCCCCCOO T3
| |
| |
OCOCOCOO T126
OOOOCCCC T127

EST only supports SetGate operation, which implies that the gates are set to either open or close at a given time interval. However, when both frame preemption (FPE) and EST are enabled, the GCL also supports Set-and-Hold-MAC and Set-and-Release-MAC operations, in addition to the SetGate operation. To enable the support of hold and release operations, the format of the GCL is slightly changed while configuring and enabling the FPE. The first traffic class (TC0) is always programmed to carry preemption traffic and therefore it is always open. The bit corresponding to TC0 is renamed as Release/Hold MAC control.

The TX queues whose packets are preemptable are indicated by setting the PEC field of the MTL_FPE_CTRL_STS register. The GCL field of the corresponding queue is ignored and considered as always open. So, even if the software writes a 0 (C), it is ignored for such queues.
Table 169.  Gate Control List When FPE is Enabled
Gate Control (up to 7 bits) Release/Hold Indication Time Interval (ns) 16, 20, or 24 bits
CCCOOOO 0 T0
CCCCOOO 0 T1
OCCCOOO 1 T2
COCCOOO 1 T3
CCOCOOO 1 T4
CCCOOOO 0 T5
CCCCOOO 0 T6

When the Release/Hold bit transitions from a 0 to 1, a Set-and-Hold-MAC operation is performed. This marks the end of the preemptable traffic. This is achieved by sending a hold request to MTL ha ns in advance (where ha is the time interval mentioned in the hold advance (HADV) field of the MTL_FPE_Advance register). Set the LBHT field (bit[7]) of the MTL_FPE_CTRL_STS register to 1, to start hold operation from second row (when the Release/Hold field is 1) after new GCL is installed, irrespective of the value of Release/Hold field in the first row of GCL; that is, 0 to 1 transition on the Release/Hold field is not necessary.

When the Release/Hold bit transitions from a 1 to 0 a Set-and-Release-MAC operation is performed. This marks the resuming of the preemptable traffic. This is achieved by sending a release request to MTL ra ns in advance (where ra is the time interval mentioned in the release advance (RADV) field of the MTL_FPE_Advance register).The preemptable traffic is blocked for the time duration the Release/Hold bit is set to a 1 in the gate control list.
Note: The value of HADV must be equal to the time required to transmit minimum_fragment_size + IPG/EIPG + Preamble, in nanosecond.

Impact of Preemption on Credit Based Shaper

In the credit based shaper (CBS), the definition of transmit is as follows:

  • TRUE- For the duration of frame transmission from the queue.
  • FALSE - When frame transmission from the queue is complete.

When you use the CBS algorithm along with frame preemption, the value of transmit is TRUE only while the frame is being transmitted by the MAC. If the frame transmission is delayed or interrupted (for instance, a preemptable frame transmission is interrupted to allow the transmission of an express frame from a different queue, or the start of express frame is delayed because a preemptable frame is being transmitted) the value of transmit is FALSE until transmission of the frame commences or is resumed.

Also, the value of transmit is FALSE during the transmission of any overhead that is a consequence of frame preemption. For example, additional frame overhead (mCRC, fragment count) that is added to the preemptable frame. At any given time, if there are no frames in the queue, and the value of transmit is FALSE, and credit is a positive value, the credit value is set to zero if there is no preemptable frame from the queue for which transmission is in progress but has been interrupted.

mPacket Format

When the preemption capability is active, the MAC sends mPackets to the PHY. A mPacket can be one of the following:

  1. An express packet
  2. A preemptable packet
  3. An initial fragment of a preemptable packet
  4. A continuation fragment of a preemptable packet
The following figure shows the mPacket format for initial fragment of a preemptable packet and the mPacket format for continuation fragment of a packet.
Figure 82. mPacket Formats
The details of the fields of the mPacket are as follows:
  • Preamble - The preamble in the mPacket (a) contains seven octets. The preamble in the mPacket (b) contains six octets. Each octet contains the value of 0x55 (transmitted in order from left to right 10101010).
  • Start mPacket Delimiter (SMD) - The value of the SMD indicates whether the mPacket contains an express packet, the start of a preemptable packet (initial fragment or complete packet), or any of continuation fragments of a preemptable packet.
  • Frag_count - The frag_count is a modulo-4 counter that increments for each continuation fragment of the preemptable packet. The frag_count protects against mPacket reassembly errors by enabling detection of the loss of up to 3 packet fragments. The frag_count field is present only in mPackets with SMD-C notation (continuation fragment). The frag_count is zero in the first continuation fragment of each preemptable packet.
  • mData - The contents of the packet from the MAC, starting with the first byte after the SFD to the last byte before the FCS are sent in the mData fields of one or more mPackets for that frame. The minimum size of the mData field is 60 bytes.
  • CRC - The CRC field contains a cyclic redundancy check (CRC) and has an indication of the final mPacket of a frame. In the final mPacket of a frame, the CRC field contains the last 4 octets of the MAC frame (the FCS field). For other mPackets, the CRC field contains a mCRC value. The mCRC is calculated on the octets of the packet from the first octet of the frame (the octet following the SFD of preemption frames) to the last octet of the packet transmitted in that mPacket by performing an XOR of the calculated 32 bit CRC value of the fragment and a value of 0x0000FFFF.
The different mPacket type summary is as follows:
  • Express packet - 7 bytes of preamble, SMD-E, data, and CRC
  • Complete preemptable packet - 7 bytes of preamble, <current preemptable packet SMD>, data, CRC
  • Initial fragment (non-final) of preemptable packet - 7 bytes of preamble, <current preemptable packet SMD>, data, mCRC
  • Continuation fragments (non-final) of preemptable packet - 6 bytes of preamble, <current preemptable continuation fragment SMD>, <current preemptable continuation fragment FC>, data, mCRC
  • Final fragment of preemptable packet - 6 bytes of preamble, <current preemptable continuation fragment SMD>, <current preemptable continuation fragment FC>, data, CRC.
Note: When you enable frame preemption, all the packets processed by the offload engines (ARP, PTO) and PMT, PTP, PAUSE, and PFC packets must be received as express/normal packets. The offload engine logic and functions do not recognize preemption frames.

Verify and Respond mPackets

When FPE function is present, the MAC can receive and detect the Verify and Respond mPackets, even when FPE is not enabled by software. When MAC detects valid Verify/Respond mPackets, it notifies the software by setting the RVER and RRSP fields of MAC_FPE_CTRL_STS register respectively. Optionally an interrupt can be generated. As such packets have empty (all-zero) data payload, they are dropped inside the MAC and not forwarded to the MRI.

Software can set the SVER and SRSP fields of MAC_FPE_CTRL_STS register to request MAC to transmit Verify and Respond mPackets respectively. Upon successful transmission of these frames, MAC clears the SVER/SRSP bits and sets the TVER and TRSP fields of MAC_FPE_CTRL_STS register. Optionally an interrupt can be generated when these events occur.

When you enable frame preemption the following rules apply:,

  • For the preemption frames received with CRC error indication, ignore the following status fields:
    • Packet length
    • Dribble error indication
    • Runt frame indication
  • The preemption frames received with CRC error and with sizes ranging from 64 to 67 bytes are treated as runt packets. So, the corresponding MMC RX frame counter for runt frames is incremented.
  • Do not disable CRC checking on receive. This is required because, internally, FPE error fragments are identified using CRC checks. For more details, see the DCRCC field in the MAC_Ext_Configuration register.
  • Forward undersized good packets (FUP) field of MTL_RxQ_Operation_Mode register must not be set. A new programmable mode bit (ARV) to autogenerate a respond packet upon receiving a verify packet is added.