[c-nsp] Flow Control and 10GE interfaces

Marian Ďurkovič md at bts.sk
Tue Nov 24 03:00:51 EST 2009


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.



More information about the cisco-nsp mailing list