On Mon, 2007-08-20 at 23:40 -0400, Peter Memishian wrote:
> > PauseFrame setting Requirement:
>  > 
>  > 1. what is the command like?
>  >    For example, 
>  >    dladm set-linkprop -p flowcontrol={"",rx,tx,both} bge0
>  > 
>  >    "": NULL string, 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
>  >    rx: it means we could receive incoming pause frames from
>  >        peer
>  >    tx: it means we could transmit pause frames to peer
>  >    both: it means we could both receive and transmit pause
>  >        frames from/to peer


A quick note.  Many older devices will only support "both" or "".

Some older devices will support configuring the logical equivalent of
"rx", but won't have a way to "expose" that to the link peer.

For example, various tulip clones have a way to configure whether the
board sends pause frames or not, although they lack any notion of
negotiating the asymetric pause with their peer.

This whole arena is a bit of a mess, and I'm not entirely sure we've
quite got it right... the proposal above is certainly simple from an
administrator's view, but I worry that it might be *too* simplistic.

Until we get a lot more operational experience with pause support, lets
make sure we don't expose whatever we do at a commitment level higher
than Uncommitted.  (And Volatile might be better still.)

With that notion, perhaps leaving pause support out of the UI proper
(leave it a private tunable for now) might be best.  I'm just afraid
that we will find out that we've not got it quite right, and will wind
up regretting making something too committed before it has fully gelled.

        -- Garrett
>  > 
>  >    If the requested flowcontrol value is not applicable to
>  >    device, "flowcontrol" will remain old value and -- change
>  >    to system.
> 
> And the default is the empty string?
> 
> --
> meem
> _______________________________________________
> networking-discuss mailing list
> networking-discuss at opensolaris.org


Reply via email to