[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, [EMAIL PROTECTED] 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 _______________________________________________ driver-discuss mailing list driver-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/driver-discuss
