On Mon, 23 Nov 2009 11:40:17 -0800 (PST), Kevin Graham wrote > > The answer is very simple: if someone thinks that ethernet flow > > > control is the answer, the burden of proof is on them to answer > > difficult questions about what the actual problem is, what flow > > control is going to solve, and why they think that it won't cause more > > problems than its worth. At best it does nothing, realistically it > > interferes with TCP flow control, and at worst it pauses your storage > > and breaks every client. > > My understanding of this must be broken... If the pause frame is sent > only sent when or immediately before RX buffers are exhausted, then > TX queuing is triggered (hopefully only briefly before those buffers > are exhausted). This would seem to trigger behavior consistent w/ a > congested interface (which in fact it is, just prior to reaching line > rate, as the receiver can't take it off interface buffers fast enough).
Yes, what you described is basically a case where the interface runs at faster speed than the data path behind it. Some examples: oversubcribed 10GE card with only 8 Gbps bandwidth to the switch fabric or system bus, 100 Mpbs ethernet interface in front of 34 Mbps microware link. This is exactly the *only* situation, where classic flow control makes sense and does really help, since it properly triggers output queueing at the sending side when the real data-path speed is reached. Any other usage is likely to cause more problems than benefits. With kind regards, M. _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/