[ofa-general] RE: [ofw] skipping QP states during transitions
Leonid Keller
leonid at mellanox.co.il
Thu Jun 11 08:28:07 PDT 2009
Mellanox HCA doesn't support multiple commands to the same QP.
Driver prevents this case with a mutex, taken in the beginning of
modify-qp and query_qp.
> -----Original Message-----
> From: ofw-bounces at lists.openfabrics.org
> [mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of Fab Tillier
> Sent: Friday, June 05, 2009 9:04 PM
> To: Sean Hefty; Tzachi Dar; general at lists.openfabrics.org;
> ofw at lists.openfabrics.org
> Subject: RE: [ofw] skipping QP states during transitions
>
> >> Look at the IB spec on section 10.3
> >
> > I was just exploring whether any hardware, separate from
> the existing
> > software stacks, supported 'skipping' QP states -- assuming
> necessary
> > values for the other states were also given. In theory, hardware
> > could walk through the states internally. The motivation is to
> > decrease the time to connect QPs by reducing the number of commands
> > that need to be issued to the hardware.
>
> Assuming the hardware processes commands in the order they're
> submitted (at least per serializes commands by resource), the
> HCA driver should be able to queue up the various modify
> commands so that they are executed by the HCA driver
> back-to-back. A failure anywhere in this process should
> cause all subsequent commands to fail due to the QP being in
> the wrong state.
>
> A single IOCTL could generate multiple back-to-back
> asynchronous QP modify requests.
>
> This would eliminate the command completion processing time
> from the QP modify.
>
> However, you need to have async QP modify support in the HCA
> driver, and ideally the HW needs to be able to process
> multiple commands issued against a single QP properly
> (Tzachi, is this something the Mellanox HCAs support?) Note
> that if the HW driver cannot process multiple commands
> outstanding for a single resource, the driver could queue up
> the commands and issue the next from the DPC as soon as the
> first is completed. In the current model, the DPC has to
> wake up the blocked thread which does whatever post
> processing of the command and unwinds to the caller, who then
> has to make the next blocking QP modify call.
>
> -Fab
> _______________________________________________
> ofw mailing list
> ofw at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
>
More information about the general
mailing list