Messages in this thread |  | | Subject | Re: [PATCH 00/13] ibmvfc: initial MQ development | From | Hannes Reinecke <> | Date | Wed, 2 Dec 2020 13:03:18 +0100 |
| |
On 11/26/20 2:48 AM, Tyrel Datwyler wrote: > Recent updates in pHyp Firmware and VIOS releases provide new infrastructure > towards enabling Subordinate Command Response Queues (Sub-CRQs) such that each > Sub-CRQ is a channel backed by an actual hardware queue in the FC stack on the > partner VIOS. Sub-CRQs are registered with the firmware via hypercalls and then > negotiated with the VIOS via new Management Datagrams (MADs) for channel setup. > > This initial implementation adds the necessary Sub-CRQ framework and implements > the new MADs for negotiating and assigning a set of Sub-CRQs to associated VIOS > HW backed channels. The event pool and locking still leverages the legacy single > queue implementation, and as such lock contention is problematic when increasing > the number of queues. However, this initial work demonstrates a 1.2x factor > increase in IOPs when configured with two HW queues despite lock contention. > Why do you still hold the hold lock during submission? An initial check on the submission code path didn't reveal anything obvious, so it _should_ be possible to drop the host lock there. Or at least move it into the submission function itself to avoid lock contention. Hmm?
Cheers,
Hannes -- Dr. Hannes Reinecke Kernel Storage Architect hare@suse.de +49 911 74053 688 SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
|  |