从流控想到的一些问题

       最近公司做交换机，流控出了一些问题，虽然流控实际使用并不多，但是从这个问题的分析，了解到交换芯片内部缓存和队列管理的一些核心问题，还是比较有价值的。
       公司使用的是marvell的6097芯片，测试部测试流控的时候，发现无法产生流控背压，测试方法是端口入限速，然后发送大于限速的流，当时我认为这种测试方法是不对的，因为policing是丢包的，既然丢包了，那么缓冲区就不会填满，缓冲区不填满，就不会产生流控。

      在这样的假设下，我让测试人员把包要发往的出端口做出限速，制造拥塞，果然流控背压产生了。
      但是接下来的问题是，为何别的交换芯片入限速就可以产生流控帧呢，后来仔细查看交换芯片手册和SDK之后，发现了如下的情况，在端口入限速的policing设置中，对于取不到令牌的包，可以有动作的设置，是丢弃还是产生流控，后来经过了解，原来是中国电信有这样的变态要求，需要限速后也能产生流控，所以很多芯片厂商就支持了。

      关于出端口拥塞是如何导致入端口产生流控的，因为交换芯片里，出和入是多对多的关系，如何知道是哪个入端口发包太多导致拥塞而要产生流控呢？

     经查，大概是这样一个过程，首先有包从port1进来，就会去请求一个空的发送队列项，如果发送队列项已经无法获取，就说明所有出端口都用塞了，那么就说明交换芯片发生了整体拥塞，这个时候port1就需要往外发送流控。如果能取到队列项，当知道这个队列项应该入哪个发送队列而又无法进入的时候（队列满），队列管理器就会去查询看看队列里哪个源端口发送的包最多，就会往这个端口发出流控帧。

     在BCM芯片里，只有包已经知道应该发送到哪个出端口，才会入缓存和队列，而每个发送队列有自己的固定长度，而包进入交换芯片转发是线速的，就不会在ingress方向产生拥塞，所以所有缓存的包都对应到出端口上，而出端口队列长度固定，所以整个交换芯片的缓存可以有固定的大小就够了。而整个缓存对入端口来说，可能有的端口占用的多，有的占用的少，这就是共享缓存的原理。很有可能出现某一个端口进入的包把别的端口的发送队列都堵死而导致别的端口进入的包无法发送的情况。采用RED算法可以在一定程度上预防这种情况。

     但是在marvell这个芯片里，包进入后就会分配一块内存和一个队列项指针，但是并不知道会进入哪个队列，这样会不会导致某个端口进入的包在入方向拥塞，然后填满整个缓冲而使得别的端口的发送队列虽然是空的，但是包进不了缓冲而无法发送的情况呢？实际上这种情况不会产生，由于交换芯片的限速转发能力，包通过查表马上知道自己将要进入哪个发送队列，如果队列满，则对应的缓冲区马上就会释放，只要在出口上对每个端口的队列长度有限制，就不会导致从一个端口发到另一个端口拥塞的包会填满整个缓冲区。

     另外再说说shaping，按照shaping的原理，对于得不到令牌的包，不是丢弃而是放在缓冲区里。shaping一般都是和调度一起结合使用的，当调度器调度到某个包要发送的时候，就需要用shaping的令牌桶去算一把，如果有足够令牌，则可以发送，如果没有足够的令牌包继续再队列里等下一次调度。对于一个100M的端口，调度器的调度能力肯定是100M，有下面三种情况可能导致拥塞，1发到这个端口的流超过100M，2流控关闭mac控制器导致调度器无法发包 3 shaping导致调度的包无法通过。


     队列的作用：
1暂时把包存放一下等待调度器调度
2 突发流缓冲
3使用RED算法的时候，可以从流里随机丢一些包而不是一段丢一段不丢。队列并不能减缓拥塞，而是在拥塞的时候，为处理拥塞提供了一种工具。就像高速上堵车，如果车没有按照车道排好等待交警调度，那么乱七八糟的整个拥堵就无法得到有效处理。