[Dynamic buffer] Updating peer response from a fixed value to dynamic…

…ally calculating #870

Change to calculate the buffer to handle peer response time according to the operating speed, instead of taking a fixed number. According to the definition in IEEE 802.3 31B.3.7 at different operating speeds, the peer response time is also different. This enhancement is to describes how to calculate the buffer needed to handle the peer response time.

doc/qos/dynamically-headroom-calculation.md

@@ -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:
 
@@ -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`