On (08/17/07 14:31), Raymond LI - Sun Microsystems - Beijing China wrote:
> PauseFrame setting Requirement:
>
> 1. what is the command like?
> For example,
> dladm set-linkprop -p mac_flowctrl={rx,tx,bi,no} -i bge0
>
> rx: it means we could receive incoming pause frames from
> peer
> tx: it means we could transmit pause frames to peer
> bi: it means we could both receive and transmit pause
> frames from/to peer
> no: it means we don't have flow control enabled. We will
> not respond to pause frames incoming and will not send
> out pause frames when congestion happens
>
> If the requested flowcontrol value is not applicable to
> device, mac_flowctrl will remain old value and no change
> to system.
I like the CLI that Raymond proposes- I think it is much easier
to understand and use, compared to the existing definitions
in the ieee802.3(5) man page..
On a related note, Raymond and I were looking at this
and found several inconsistencies in the pause/asmpause
definitions in the man page (no surprise that everyone comes
out of reading that man page confused!)
First off, my truth table at
http://mail.opensolaris.org/pipermail/brussels-dev/2007-July/000337.html
which was derived purely from Seifert's explanation at
http://hardware.mcse.ms/message13052.html)
(seems to?) match the truth table in the Solaris man page.
Let's take one particular case: at the bottom of ieee802.3(5), the man
page says
AA AP LAC LPC LA LP Description
1 0 1 1 1 0 Local station will Tx
a pause when Rx is
congested.
which would correspond to the {my = 01, peer = 11} case
in http://mail.opensolaris.org/pipermail/brussels-dev/2007-July/000337.html
where I arrive at the same result (asym-to). To spell it out
explicitly, in this particular case, we would ignore any pause fames
that we receive, but we would *transmit* pause frames if the receive is
congested.
But, when we look at the definition of adv_cap_pause in ieee802.3(5)
(earlier in the man page) we have
adv_cap_pause
The meaning of this statistic depends on the value provided by
adv_cap_asmpause.
if adv_cap_asmpause = 1
:
0
Pause transmission when a pause frame is received.
this would be in direct contradiction to the result
in the man page's own truth table, as well as the note at
http://hardware.mcse.ms/message13052.html which says:
"3) I can *assert* flow control, but cannot respond (i.e., I
want to be able to send PAUSE frames, but I will ignore any you send
me). [Encoded as PAUSE=0, ASM_DIR=1. Note the backwards compatibility
again; a legacy "symmetric-only" device will see this advertisement as
"I have no flow control capability", since PAUSE=0; this is the proper
interpretation, since the legacy device wants "all or nothing", not
"receive my messages but don't send any of your own".]"
This contradiction in the man page also explains why Garrett and
I arrived at slightly different truth tables.
So, given the mayhem in the current definitions, I propose that we
should just purge the confusing definitions (and associated attempts
at driver implementations) in ieee802.3(5) man page and instead
implement
http://mail.opensolaris.org/pipermail/brussels-dev/attachments/20070817/720b852b/attachment.txt
Thoughts?
--Sowmini
