[openib-general] ib_mad.c comments

[Michael S. Tsirkin]

Hello, Sean!
I am not arguing against queuing sends and processing them later
(if only because it guarantees non-starving processing of the mads).
Its only generating fake failed completions that does not make sence to me.

Quoting r. Sean Hefty (sean.hefty at intel.com) "RE: [openib-general] ib_mad.c comments":
> >> Personally, for an initial implementation, I'd just go with posting
> >> work requests, and generate completions for sends that cannot be
> >> posted.  This should be fairly trivial to implement, yet still work.
> >
> >In that case, it would be sufficient to return an error code to the caller.
> >If the caller wants to re-use the completion routine at this point,
> >let him.
> 
> For sends without a timeout specified, I agree that it makes sense to just
> return a failure, but for sends with a timeout, this would prevent the
> caller from taking advantage of the access layer tracking the timeout
> period.
> 
> For example, if the caller tries to resend the MAD immediately, it's likely
> to fail again.  It seems like it would be beneficial to indicate the failure
> after a given time period, which may give a retry a better chance of
> succeeding.

But this is a question of policy, is it not?
If we need a generic timeout function, lets have it
and let the caller use it if thats what is needed.
No need to force the policy.

> Thinking about this a little more, I'm guessing that the access layer will
> already have to allocate a structure to track all sends in order to match
> responses with requests, so queuing sends is probably just as easy to
> implement now as not.

Here you are talking about the option to queue the sends,
and although you likely need a separate queue for these,
I am not against it, its only generating fake failed completions
that does not make sence to me.

MST