Hi, working on QoS configuration on 8 Gbps plataform I face these comment (see below) on "Brocade Fabric OS Administration Guide, 7.4.1 - 53-1003939-04:page 403Limitations and restrictions for QoS zone-based traffic prioritization...• If QoS is enabled, an additional 16 buffer credits are allocated per port for 8-Gbps ports in Extended Mode (LE).Refer to Managing Long-Distance Fabrics on page 533 for information about buffer credit allocation in extended fabrics.page 533• Extended Mode (LE) — LE configures the distance for an E_Port when that distance is greater than 5 km and up to 10 km. LEdoes not require an Extended Fabrics license. The baseline for the buffer credit calculation is one buffer credit per km at 2 Gbps.This allocation yields the following values for 10 km:...– 40 buffer credits per port at 8 GbpsCould someone explain how "QoS enabled on 8-Gbps ports in Extended Mode (LE)" works? If traffic prorization using VC-Virtual Channels (High, Medium and Low Priority VCs) is applied or just 16 buffer credits are added, totaling the value of 56 buffer credits to VC2 in this ISL E_Ports?Greetings from Brazil!!!
I believe that your QoS-enabled LE port will really have 56 buffers. And I think you can actually allocate even more (portCfgEportCredits) if you need, e.g. if your distance is really close to 10km and you expect a lot of short frames. Or maybe this command already needs a long distance license? I'm not sure about it, sorry...Why do you mention VC2? Do you plan to configure the R_RDY ISL instead of VC_RDY?
The buffers will be used by all the VCs and the sharing scheme is rather complicated. I once spend a couple of weeks in escalation to L2 and L3 so that they explain me how it works and I'm still not sure I understand it right, but I'll try to explain. There are two modes: normal and buffer starvation (or credit starvation?)In normal mode everything is working fine and the credit allocation is not controlled. All the credits are shared between all the VCs. So the frames just travel in a round-robin way, one frame from each VC in turn, which makes that 5 high prio frames are sent, then 4 mid prio, then 2 low prio, then process repeats. If a VC doesn't currenty have any frame to send, it is simply skipped.When something stucks and the number of credits becomes low, the starvation mode engages. It then divides the rest of credits between the VCs and stops treating them as shared. The credits are divided inequally - according to the VC prio rank. Since the credits are not shared anymore, if one of the VCs already doens't have a credit to send a frame, it just can't send it and waits for the next turn. This makes sure that the stuck VC doesn't affect other VCs.
Hope that helps.
Hi Alexey StepanovThank you very much, this has helped me to understand how it works.Why do you mention VC2? Do you plan to configure the R_RDY ISL instead of VC_RDY?I've just mentioned VC2 because I supposed that ISLs on LE Mode runs like on LD Mode (Long Distance mode).Note: QoS doesn't run o Long Distance mode when configured and activated.Best Regards!