Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Dynamic buffer] Updating peer response from a fixed value to dynamically calculating #870

Merged
merged 5 commits into from
Nov 15, 2021
Merged

[Dynamic buffer] Updating peer response from a fixed value to dynamically calculating #870

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
e3ef045
Update dynamic buffer calculation HLD
keboliu Aug 20, 2021
085ff23
rephrase the description
keboliu Aug 31, 2021
2bb22a2
Update doc/qos/dynamically-headroom-calculation.md
keboliu Sep 13, 2021
11fed3d
Update dynamically-headroom-calculation.md
keboliu Sep 13, 2021
079df5d
fix review comments
keboliu Nov 12, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 17 additions & 1 deletion doc/qos/dynamically-headroom-calculation.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -746,7 +746,20 @@ Let's imagine what will happen after a XOFF frame has been sent for a priority.
1. MAC/PHY delay, which is the bytes held in the SWITCH CHIP's egress pipeline and PHY when XOFF has been generated.
2. Gearbox delay, which is the latency caused by the Gearbox, if there is one.
3. KB on cable, which is the bytes held in the cable, which is equals the time required for packet to travel from one end of the cable to the other multiplies the port's speed. Obviously, the time is equal to cable length divided by speed of the light in the media.
4. Peer response time, which is the bytes that are held in the peer switch's pipeline and will be send out when the XOFF packet is received.
4. Peer response time. When a switch receives a pause frame, it will not stop the packet transmission immediately, because it needs to drain the frames which already been submitted to the MAC layer. So extra buffer shall be considered to handle the peer delay response. IEEE 802.3 31B.3.7 defines how many pause_quanta shall wait upon an XOFF. A pause_quanta is equal to the time required to transmit 512 bits of a frame at the data rate of the MAC. At different operating speeds, the number of pause_quanta shall be taken are also different. Following table shows the number of pause_quanta that shall be taken for each speed.


| Operating speed | Number of pause_quanta |
|:--------:|:-----------------------------:|
| 100 Mb/s | 1 |
| 1 Gb/s | 2 |
| 10 Gb/s | 67 |
| 25 Gb/s | 80 |
| 40 Gb/s | 118 |
| 50 Gb/s | 147 |
| 100 Gb/s | 394 |
| 200 Gb/s | 453 |
| 400 Gb/s | 905 |

Let's consider the flow of XOFF packet generating and handling:

Expand All @@ -773,6 +786,9 @@ Therefore, headroom is calculated as the following:
- `cell occupancy` = (100 - `small packet percentage` + `small packet percentage` * `worst case factor`) / 100
- `kb on cable` = `cable length` / `speed of light in media` * `port speed`
- `kb on gearbox` = `port speed` * `gearbox delay` / 8 / 1024
- `peer response` =
- if can get a valid pause quanta, `peer response` = (`number of pause_quanta` * 512) / 8
- otherwise, use the default value, `peer response`: ASIC_TABLE|\<asic name\>|peer_response_time
- `propagation delay` = `port mtu` + 2 * (`kb on cable` + `kb on gearbox`) + `mac/phy delay` + `peer response`
- `Xon` = `pipeline latency`
- `Xoff` = `lossless mtu` + `propagation delay` * `cell occupancy`
Expand Down