[prev in list] [next in list] [prev in thread] [next in thread]
List: opensolaris-sysadmin-discuss
Subject: Re: [sysadmin-discuss] [driver-discuss] [networking-discuss]
From: Raymond LI - Sun Microsystems - Beijing China <Raymond.Li () Sun ! COM>
Date: 2007-08-17 6:31:32
Message-ID: 46C540C4.5080706 () sun ! com
[Download RAW message or body]
Guys,
I made a draft of implementation of our new UI to set flowcontrols.
Please find it in attachment. Looking forward to your suggestions.
Thanks,
Raymond
Raymond LI - Sun Microsystems - Beijing China wrote:
> Rainer Heilke wrote:
>
>> Sorry, I haven't really been part of this discussion. Here are my
>> votes/opinions.
>>
>> Raymond LI - Sun Microsystems - Beijing China wrote:
>>
>>
>>> Guys, would we come up with some conclusion on this?
>>>
>>> 1. What UI to provide, meaningful strings or numerical on/off?
>>>
>>>
>>>
>> I vote for meaningful strings.
>>
>>
>>> I think all of us agree to have a more straightfoward UI for customer
>>> to config.
>>> And we have below two proposed UI so far.
>>> (1) flowcontrol = {send, accept, disable, both}
>>> (2) accept_pause = {0, 1}, send_pause = {0, 1}
>>> Seems (1) is more concise.
>>>
>>>
>>>
>> Flow control seems clearer.
>>
> OK, let's do that with flowcontrol and string values.
>
>>> 2. Will we still keep our ieee802.3(5) manpage definations as
>>> underlying implementation?
>>> I think before IEEE has new idea on them, we just keep them as what
>>> they are today.
>>>
>>>
>>>
>> Not sure on this one.
>>
>>
>>> But we don't provide interfaces to directly tune them anymore. User
>>> still could check the
>>> values as read-only for debug/diag purpose.
>>>
>>>
>>>
>> If we can't tune them, we should at least have a way of determining them.
>>
> Yes, I think this will determine when flowcontrol is set to some value.
> And this will avoid that
> different drivers have different parsing.
> _______________________________________________
> driver-discuss mailing list
> driver-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/driver-discuss
>
["pause.txt" (text/plain)]
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.
2. We discuss 4 cases regarding implementation below:
case (1) is for not pause capable devices
case (2) is for asym pause only capable device[TBD, I don't
know if such device exists in real world]
case (3) is for devices like 100M ethernet which does not
support asym pause
case (4) is for full pause capable devices
/* := means "value assignment", => means derive */
IEEE802.3 pause frame protocol parameters will be hide
from UI but still remain accessiable via kstat. Below description
is based on IEEE std802.3(1998), Table 37-4
User will not be able to config flowcontrl via ndd anymore.
The only UI we provide will be dladm, which provides better
user experience.
case (1) Device is not pause capable
So we have "cap_pause == 0, cap_asmpause == 0"
=> We could only have "adv_cap_pause & adv_cap_asmpause == 0"
[UI]
- In this case, setting "rx/tx/bi" will fail and default value
of "mc_flowctrl" remain "no" unchanged.
- The only legal value is "no", and we need to set
"adv_cap_pause" and "adv_cap_asmpause" to 0
mc_flowctrl = "rx/tx/bi" return failure
mc_flowctrl = no: adv_cap_pause := 0, adv_cap_asmpause := 0
[DEFAULT]
mc_flowctrl == no
[dladm show-ether]
Just for example, which shows 4 bge devices with all
possible values
#dladm show-ether
link param state autoneg speed(Mb/s) duplex pause
bge0 current up 1 1000 full no
bge1 current up 1 1000 full tx
bge2 current up 1 1000 full rx
bge3 current up 1 1000 full bi
case (2) Device is only asymmetric pause capable
So we have "cap_pause == 0, cap_asmpause == 1"
=> We have "adv_cap_pause == 0" always
=> But adv_cap_asmpause tunable between 0 and 1
[UI]
mc_flowctrl = rx: failure, can't be set, which means
no possible value of adv_* to enable
the "rx"
mc_flowctrl = tx: adv_cap_pause == 0, adv_cap_asmpause := 1
on condition that:
lp_cap_pause == 1, lp_cap_asmpause == 1
mc_flowctrl = bi: failure, can't be set
mc_flowctrl = no: adv_cap_pause == 0, adv_cap_asmpause := 0
[DEFAULT]: mc_flowctrl == no
(3) Some devices like 100M ethernet doesn't support asymmetric
pause features. We implements like below:
if cap_pause == 1, cap_asmpause == 0
=> adv_cap_pause tunable 0/1
=> adv_cap_asmpause == 0
[UI]
mc_flowctrl = rx: failure, can't be set
mc_flowctrl = tx: failure, can't be set
mc_flowctrl = bi: adv_cap_pause := 1, adv_cap_asmpause == 0
on condition that:
lp_cap_pause == 1
mc_flowctrl = no: adv_cap_pause := 0, adv_cap_asmpause == 0
[DEFAULT]: mc_flowctrl == no
(4) if cap_pause == 1, cap_asmpause == 1
=> adv_cap_pause and adv_cap_asmpause tunable
[UI]
mc_flowctrl = rx: adv_cap_pause := 1, adv_cap_asmpause := 1
on condition that:
lp_cap_asmpause == 1, lp_cap_pause == 0
mc_flowctrl = tx: adv_cap_pause := 0, adv_cap_asmpause := 1
on condition that:
lp_cap_asmpause == 1, lp_cap_pause == 1
mc_flowctrl = bi: adv_cap_pause := 1, adv_cap_asmpause := 1
on condtion that:
lp_cap_pause == 1
mc_flowctrl = no: adv_cap_pause := 0, adv_cap_asmpause := 0
[DEFAULT]:
mc_flowctrl == no
[kstat]
For example, when we set mc_flowctrl = tx successed,
we could see kstat like this:
#kstat -p bge:0
... ...
bge:0:mac:adv_cap_asympause 1
bge:0:mac:adv_cap_pause 0
... ...
bge:0:mac:cap_asmpause 1
bge:0:mac:cap_pause 1
... ...
bge:0:mac:lp_cap_asmpause 1
bge:0:mac:lp_cap_pause 1
And if we set rx not success, we could check what is wrong
by kstat as well
_______________________________________________
sysadmin-discuss mailing list
sysadmin-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/sysadmin-discuss
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic