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

[sowmini.varadhan at sun.com]

[replacing all the opensolaris groups that I dropped by mistake]

On (07/30/07 14:12), Garrett D'Amore wrote:
> 
> On Mon, 2007-07-30 at 16:38 -0400, sowmini.varadhan at sun.com wrote:
> > On (07/26/07 11:17), Garrett D'Amore wrote:
> > >     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
> > > 
> > 
> > Garrett, 
> > 
> > trying to catch up on this thread in the midst of diskless boot and
> > cdkit hell, and trying to understand the truth table here. 
> > 
> > So I read the explanation from Rich Seifert, and tried to deduce
> > the full truth table from there - I'm trying to map my results
> > with yours and getting some mismatches, possibly due to not 
> > understanding your definitons of "tx" and "rx". Here is what I have
> > 
> > One each axis, the 2 bits are (pause, asmpause)
> > 
> > I think that the "01" case is not meaningful in practice, 
> > because the discussion says that rx is harder to implement than
> > send. But let's keep it for the sake of discussion.
> > 
> > e.g.,  my 10 means pause = 1, asmpause = 0. I believe this corresponds
> >        to "tx" in your table (??)
> > 
> >               \ peer 
> >       my       \  00      01     10      11    
> >                 \-----------------------------
> >          
> >           00      -       -      -       -
> > 
> >           01      -       -      -      asym-to
> > 
> >           10      -       -     sym     sym
> >  
> >           11      -     asym-   sym     asym-both
> >                         from
> > 
> > where
> >     -  == no flow control
> >    sym == symmetric flow control
> >    asym-from == "asymmetric, from partner only"
> >    asym-to == "asymmetric, to partner only"
> >    asym-both == "asymmetric, both ways"
> > 
> > Don't we have a mismatch for the (tx, tx) case, which would correspond
> > to (10, 10) in my table? Or am I misunderstanding your definitions?
> 
> Your table is easier to understand... probably because it uses the
> definitions as used by 802.3.  I was trying to invent some new way of
> expressing this information, but clearly it was unclear. :-)
> 
> So lets stick with what you have for the moment.
> 
> The case for (11, 11) is really "symmetric" as well.  Basically, for any
> case where (1?,1?), the result will be symmetric flow control.
> 

right.

and I noticed in my table that there are only 6 real non "dash"
cases to consider.

> So, lets assume for the moment, that managing these flow control bits is
> an "advanced" user activity.  If we make that assumption, then we can
> use the 802.3 bits as in the table above for tuning, but I would also
> create two other properties:

right, but we still have to define some easily understandable input:
just do the 2 bits for "my" and let the user figure out the final
result by looking up the table above?

> * flow-control = on/off .... enables or disables all flow control
> (overriding the 802.3 bits)

i.e., my 00 or 11 case, right?

> * flow-control-status = off, tx, rx, on.  (result of 802.3 negotiation,
> where off = none, tx = asym-to, rx = asym-from, and on = sym.)  We can
> use other strings as values if this is too confusing. :-)

yes, and as son as we have chosen some satisfactory strings, 
we'd have covered the 6 non-null values in the table above, I believe.

> The main thing is to let users forcibly enable/disable flow control (and
> asymmetric tuning is unlikely to find much use in the field, I
> hypothesize), and also see what the current link status is.
> 
> 	-- Garrett

--Sowmini