On 7/23/2018 11:53 AM, Max Gurtovoy wrote: > > > On 7/23/2018 7:49 PM, Jason Gunthorpe wrote: >> On Fri, Jul 20, 2018 at 04:25:32AM +0300, Max Gurtovoy wrote: >>> >>>>>> [ 2032.194376] nvme nvme0: failed to connect queue: 9 ret=-18 >>>>> >>>>> queue 9 is not mapped (overlap). >>>>> please try the bellow: >>>>> >>>> >>>> This seems to work. Here are three mapping cases: each vector on its >>>> own cpu, each vector on 1 cpu within the local numa node, and each >>>> vector having all cpus in its numa node. The 2nd mapping looks kinda >>>> funny, but I think it achieved what you wanted? And all the cases >>>> resulted in successful connections. >>>> >>> >>> Thanks for testing this. >>> I slightly improved the setting of the left CPUs and actually used >>> Sagi's >>> initial proposal. >>> >>> Sagi, >>> please review the attached patch and let me know if I should add your >>> signature on it. >>> I'll run some perf test early next week on it (meanwhile I run >>> login/logout >>> with different num_queues successfully and irq settings). >>> >>> Steve, >>> It will be great if you can apply the attached in your system and >>> send your >>> findings. >>> >>> Regards, >>> Max, >> >> So the conlusion to this thread is that Leon's mlx5 patch needs to wait >> until this block-mq patch is accepted? > > Yes, since nvmf is the only user of this function. > Still waiting for comments on the suggested patch :) Hey Sagi, what do you think of Max's patch? Max, should you resend this in a form suitable for merging? Thanks, Steve. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
