[ofw] typical values for ci_umv_buf_t

Fab Tillier ftillier at windows.microsoft.com
Sun Mar 16 09:10:34 PDT 2008


In that case there's no IOCTL, though, right?

-----Original Message-----
From: Leonid Keller [mailto:leonid at mellanox.co.il]
Sent: Sunday, March 16, 2008 3:08 AM
To: Sean Hefty; Fab Tillier; ofw at lists.openfabrics.org
Subject: RE: [ofw] typical values for ci_umv_buf_t

> (Fab) Are there cases where there's a pre-IOCTL call but not a
post-IOCTL call ?
There are in the existing code.
It is used when the UVP has done all the work in the pre- call and is
not interested in ioctl.
The Uvp shows that by returning IB_VERBS_PROCESSING_DONE from the pre-
call.
(see mlnx_ual_av.c)

> -----Original Message-----
> From: ofw-bounces at lists.openfabrics.org
> [mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of Sean Hefty
> Sent: Thursday, March 13, 2008 12:54 AM
> To: 'Fab Tillier'; ofw at lists.openfabrics.org
> Subject: RE: [ofw] typical values for ci_umv_buf_t
>
> >Are there cases where there's a pre-IOCTL call but not a post-IOCTL
> >call?  I would expect things to go poorly if you use
> uninitialized memory.
> >Specifically, the kernel proxy code that marshals the
> p_inout_buf would
> >detect a bad pointer if input_size or output_size where non-zero and
> >p_inout_buf was non-zero too (unless you get 'lucky' and
> p_inout_buf is
> >a valid pointer in the app's memory space, and input_size and
> >output_size are valid for that buffer.)
>
> I'm trying to understand the requirements of the userspace
> verbs library and the kernel HCA driver, not IBALs
> requirements.  For example, how the ci_umv_buf_t data is
> conveyed to or from the kernel is an implementation issue.
> Command is only passed to the kernel, and status is only
> returned from the kernel.  I would expect the verbs library
> to ignore command in a post() call, and the kernel driver to
> ignore status.
>
> >>Does this imply that the HCA driver supports being called from an
> >>arbitrary thread context, or must it be called from the
> user's thread context directly?
> >
> >IBAL has the requirement that all IOCTLs be done in the
> context of the
> >application's thread.  This allows it to perform memory registration
> >and other such calls where being in the app's thread context is
> >required.  For other requests, if things get pushed to a
> async callback
> >work item, you can't dereference embedded pointers in the
> p_inout_buf.
> >So whether you can be called from arbitrary context depends
> on the usage of the p_inout_buf.
>
> Again, I'm asking about the requirements from the perspective
> of the HCA driver.
>
> - Sean
>
> _______________________________________________
> ofw mailing list
> ofw at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
>




More information about the ofw mailing list