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
On Tue, Nov 24, 2009 at 09:00:51AM +0100, Marian ??urkovi?? wrote:
On Mon, 23 Nov 2009 11:40:17 -0800 (PST), Kevin Graham wrote
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
On Tue, Nov 24, 2009 at 11:24:26AM -0500, Ross Vandegrift wrote:
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,
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.
OK, the vitriol towards .3x in this thread was so strong I was concerned I had
On Sun, Nov 22, 2009 at 08:28:24PM -, Matthew Melbourne wrote:
What is the general recommendation regarding enabling flow control on
Ethernet interfaces. Is it a legacy issue when devices had smaller buffers,
or is it still required for specific applications? We are having issues with
an
Hi,
On Mon, Nov 23, 2009 at 08:41:58AM -0500, Ross Vandegrift 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
Gert Doering wrote:
Hi,
On Mon, Nov 23, 2009 at 08:41:58AM -0500, Ross Vandegrift 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
Hi,
On Mon, Nov 23, 2009 at 04:05:16PM +, Phil Mayers wrote:
So indeed, flow control is not a panacea. I agree with this :-)
An interesting wrinkle (to some) is that stock flow control is not QoS
(i.e. 802.1p codepoint) aware - it's all-or-nothing, meaning your
low-bandwidth
Gert Doering wrote:
An interesting wrinkle (to some) is that stock flow control is not QoS
(i.e. 802.1p codepoint) aware - it's all-or-nothing, meaning your
low-bandwidth diffserv/EF flow gets paused as well as your less-then
best-effort 999.9mbit/sec FTP transfer :o(
There's a flow control
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Phil Mayers
Sent: lunedì 23 novembre 2009 17.05
To: Gert Doering
Cc: Matthew Melbourne; cisco-nsp@puck.nether.net; Ross Vandegrift
Subject: Re: [c-nsp] Flow Control
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
Hi,
On Mon, Nov 23, 2009 at 11:40:17AM -0800, Kevin Graham wrote:
Short of host-side implementation details such as one slow MSI-X queue
starving others, isn't this providing exactly the congestion feedback
that would be expected (queue-on-congestion, drop when queue
exceeded)?
so you have
so you have one ingress port (the NAS), 20 egress ports (the clients).
Egress port 1 fills up.
What are you going to do? Flow-control (- slow down 19 other ports)
or drop?
Agreed, egress queuing and flowcontrol send seems logically flawed, but
the NAS case I see cited is flowcontrol
On 24/11/2009, at 3:50 AM, Brian Turnbow wrote:
The nexus family does PFC (no it's not a card, they reused the acronym)
http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/white_paper_c11-542809.html
Basically enables sending a pause per class.
They did it for FCOE and it is
On 23/11/2009 21:28, Gert Doering wrote:
What are you going to do? Flow-control (- slow down 19 other ports)
or drop?
The answer to this depends on the application. If you're running regular
IP then yes, drop a few packets. No-one will care too much.
FCoE is a different matter and
Hi,
What is the general recommendation regarding enabling flow control on
Ethernet interfaces. Is it a legacy issue when devices had smaller buffers,
or is it still required for specific applications? We are having issues with
an Enterprise NAS solution where servers using it for storage are
16 matches
Mail list logo
