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: [email protected] > [mailto:[email protected]] On Behalf Of Fab Tillier > Sent: Friday, June 05, 2009 9:04 PM > To: Sean Hefty; Tzachi Dar; [email protected]; > [email protected] > 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 > [email protected] > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw > _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
