Joost Mulders wrote:
>> Could we introduce below property into Brussels while keeping current
>> IEEE802.3 defination? Having a property named "ether-flow-ctrl", which has
>> below possible values:
>>
>> ether-flow-ctrl = 0: Disable pause frame flow control
>> ether-flow-ctrl = 1: Enable just Rx flow control
>> ether-flow-ctrl = 2: Enable just Tx flow control
>> ether-flow-ctrl = 3: Enable both Rx/Tx flow control
>>
>
> Interesting reading on this subject:
> http://hardware.mcse.ms/message13052.html
>
> Flow control per direction is a far better concept than what we offer
> now. I would love to see it implemented.
>
> Regards, Joost
>
This is a good post, thanks.
cap_flow=[none,tx,rx,both]
adv_flow=[none,tx,rx,both]
peer_flow=[none,tx,rx,both]
link_flow=[none,tx,rx,both]
(tx means can accept pause frames, rx means can generate pause frames)
In the following table, the adv ability is the y axis, and the peer's
ability is in the x axis. The cells indicate the negotiated value for
link_flow.
peer=> none tx rx both
adv
none none none none none
tx none none tx tx
rx none rx none tx
both none rx tx both
A few notes: First, the peer and the adv values for asymmetric pause are
the opposite values. Second, if the negotiated value is both, it
*might* mean rx only. In particular, some NICs might not ever generate
pause frames, but they might not support the ability to indicate that.
(100Mbps NICs might not have a way to expose that via the MII bit...
This is a limitation of the way PAUSE was specified, and we can't truly
overcome it generally.)
Possibly instead of tx/rx, we could call this send_pause, accept_pause ?
-- Garrett
