> From: Hefty, Sean [mailto:sean.he...@intel.com]
> It breaks the ABI and existing apps that *do* handle BUSY replies. We
> can't assume that no apps out there aren't written correctly.
>
> The mad interface is privileged, not some generic API available to any
> user space app.
I have yet to
Sean,
What if we reversed the sense of your idea - if the app or ulp provides a
positive timeout number, apply the combined time-out concept, but if it
provides a negative number, force it to handle BUSY itself? This would provide
a good quality default behavior.
Also - it still makes sense to
:sean.he...@intel.com]
Sent: Wednesday, August 11, 2010 1:58 PM
To: Todd Rimmer; Mike Heinz; linux-rdma@vger.kernel.org; Roland Dreier; Jason
Gunthorpe; Hal Rosenstock
Subject: RE: Update proposal for handling BUSY responses from the SA/SM
> Coding IB applications is hard enough, let's not
> 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.
The mad interface is privileged, not some generic API available to any user
space app.
> I thi
> From: Hefty, Sean [mailto:sean.he...@intel.com]
>
> > 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
> 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
for handling BUSY responses from the SA/SM
> In addition to the patch itself, there has been significant discussion
> about changing the APIs to allow the application to explicitly specify how
> to handle BUSY.
The current code allows an app to explicitly handle BUSY replies, so we do
> In addition to the patch itself, there has been significant discussion
> about changing the APIs to allow the application to explicitly specify how
> to handle BUSY.
The current code allows an app to explicitly handle BUSY replies, so we don't
need changes for that. I was advocating making thi
I never got a response to our last discussions of this issue; to remind
everyone, this is a patch for handling BUSY responses from the SA in the same
manner time outs are handled. The purpose of this change is to prevent poorly
written applications from overloading the SM, or failing when they r
