[Openib-windows] A major patch

[Fabian Tillier]

Hi Leo,

On 6/8/06, Leonid Keller <leonid at mellanox.co.il> wrote:
> See below
>
> > -----Original Message-----
> > From: ftillier.sst at gmail.com [mailto:ftillier.sst at gmail.com]
> > On Behalf Of Fabian Tillier
> > Sent: Thursday, June 08, 2006 12:18 AM
> >
> > Hi Leo,
> >
> > On 6/6/06, Leonid Keller <leonid at mellanox.co.il> wrote:
> > >
> > > [MTHCA]
> > >
> > >     1. fixed (and now works) "livefish" support;
> > >
> > >     2. fixed (and now works) multiple HCA support;
> > >
> > >     3. support of work of 32-bit tools with 64-bit kernel;
> > >
> > >     4. support *bad_wr parameter in post/recv verbs as optional;
> > >
> > >     5. make the wait on a command completion alertable for user
> > > processes;
> >
> > What happens when an operation wakes up due to an alert?  I
> > assume you then resume the wait?
>
> No, and seems right wrong. But ...
>
> To recall, it's a wait on a command, sent to the HCA card.
> The real reason for that change was to facilitate cancelling of user
> applications by Ctrl-C.
>
> The original solution is:
>        1. to wait in KernelMode with timeout in non-alertable state.
>
> Other probable soutions are:
>        2. to wait in UserMode with timeout in non-alertable state. On
> alert return an error and exit.
>                it's usually allowable only for the highest-level
> drivers;
>
>        3. to wait in KernelMode with timeout in alertable state. On
> alert resume the wait.
>                it can cause an executing of an APC with a racing
> contents, e.g. the thread is waiting on a command during create_qp,
> while APC performs destroy of all the thread resources.
>
> I tend to return to the original solution as a more robust.
> What to you think ?

I think waiting in kernel mode in non-alertable state is fine - the
command shouldn't take long to complete (do they ever timeout
anymore?).

- Fab