[brussels-dev] [driver-discuss] pausel bits setting within Solaris

[Raymond LI - Sun Microsystems - Beijing China]

Garrett D'Amore wrote:
>>> One set of properties that I would dearly love to see Brussels 
>>> simplify, are the adv_pause and adv_asympause bits.   The definitions 
>>> of what these bits mean (and their brethren, link_pause, 
>>> link_asym_pause, etc.)  are baroque in the extreme.  I suspect that 
>>> this may have come about as a result of IEEE 802.3x trying to 
>>> "compress" the number of bits used in the actual MII autonegotiation 
>>> registers.
>>>
>>> It would be far, far simpler, IMO, to simply have two sets of 
>>> tunables for end users:
>>>
>>> one set representing TX direction pause (cap, adv, lp, state)
>>> one set representing RX direction pause (cap, adv, lp, state)
>>>
>>> Ultimately, for some device drivers, it will turn out that this is 
>>> simpler to code for anyway.
>>>
>>>       
>> 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
>>     
>
> If we're going to do this, why bother keeping the crummy ieee802.3 
> definitions?  Instead maybe also allow for an advertise and current 
> state properties to take these values.
>   
Just think above 0-4 definations are a subset of our currently complex 
ieee802.3 pause value matrix,
some definations might lose if we get rid of all of them.