> From: Hefty, Sean [mailto:[email protected]]
> 
> > The problem is that none of the apps **do** handle BUSY - at all -
> and your
> > proposal still requires the apps to be changed to stop them from
> degrading
> > the fabric.
> 
> Yes - the apps are busted, so I do believe that the fixes are required
> there and not in the kernel.  If you want to fix them by applying a
> work-around in a user space library, that's still doable.  Take the
> timeout/retry values provided by the app, calculate the total timeout,
> and pass that into the kernel.
> 
> - Sean

Coding IB applications is hard enough, let's not require it to be harder.  We 
need a solution that fixes all the apps and makes it easy for future 
applications to have a sensible default behavior.  

I think Mike's approach does that, minimizes risk, addresses 3rd party apps 
which may not be part of OFA, and has a path toward allowing sophisticated 
applications to control the behavior (few if any apps will really want to do 
that).

I look at this as analogous to TCP sockets and the getopt/setopt calls.  They 
allow a lot of fine grained control, however for applications which chose not 
to use them, the defaults provide good network friendly behaviors.

Having the capability in the kernel is needed so that all kernel ULPs behave 
well, including ones not under OFA control (such as Lustre and other 
filesystems).

Mike's approach also allows for the addition of more sophisticated algorithms, 
such as random backoff, to be easily added and selected in the future.

Todd Rimmer



--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to