> > - Later we can explore if nr_hw_queue more than one really add benefit. > > From current limited testing, I don't see major performance boost if > > we have nr_hw_queue more than one. > > > Well, the _actual_ code to support mq is rather trivial, and really serves > as a > good testbed for scsi-mq. > I would prefer to leave it in, and disable it via a module parameter.
I am thinking as adding extra code for more than one nr_hw_queue will add maintenance overhead and support. Especially IO error handling code become complex with nr_hw_queues > 1 case. If we really like to see performance boost, we should attempt and bare other side effect. For time being we should drop this nr_hw_queue > 1 support is what I choose (not even module parameter base). > > But in either case, I can rebase the patches to leave any notions of > 'nr_hw_queues' to patch 8 for implementing full mq support. Thanks Hannes. It was just heads up...We are not sure when we can submit upcoming patch set from Broadcom. May be we can syncup with you offline in case any rebase requires. > > And we need to discuss how to handle MPI2_FUNCTION_SCSI_IO_REQUEST; > the current method doesn't work with blk-mq. > I really would like to see that go, especially as sg/bsg supports the same > functionality ... >
