From: Leon Romanovsky <leon@kernel.org>
To: Max Gurtovoy <maxg@mellanox.com>
Cc: Steve Wise <swise@opengridcomputing.com>,
Sagi Grimberg <sagi@grimberg.me>,
Doug Ledford <dledford@redhat.com>,
Jason Gunthorpe <jgg@mellanox.com>,
RDMA mailing list <linux-rdma@vger.kernel.org>,
Saeed Mahameed <saeedm@mellanox.com>,
linux-netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH mlx5-next] RDMA/mlx5: Don't use cached IRQ affinity mask
Date: Tue, 17 Jul 2018 11:58:31 +0300 [thread overview]
Message-ID: <20180717085831.GB3152@mtr-leonro.mtl.com> (raw)
In-Reply-To: <3f827784-3089-2375-9feb-b3c1701d7471@mellanox.com>
[-- Attachment #1: Type: text/plain, Size: 2740 bytes --]
On Tue, Jul 17, 2018 at 11:46:40AM +0300, Max Gurtovoy wrote:
>
>
> On 7/16/2018 8:08 PM, Steve Wise wrote:
> > Hey Max:
> >
> >
>
> Hey,
>
> > On 7/16/2018 11:46 AM, Max Gurtovoy wrote:
> > >
> > >
> > > On 7/16/2018 5:59 PM, Sagi Grimberg wrote:
> > > >
> > > > > Hi,
> > > > > I've tested this patch and seems problematic at this moment.
> > > >
> > > > Problematic how? what are you seeing?
> > >
> > > Connection failures and same error Steve saw:
> > >
> > > [Mon Jul 16 16:19:11 2018] nvme nvme0: Connect command failed, error
> > > wo/DNR bit: -16402
> > > [Mon Jul 16 16:19:11 2018] nvme nvme0: failed to connect queue: 2 ret=-18
> > >
> > >
> > > >
> > > > > maybe this is because of the bug that Steve mentioned in the NVMe
> > > > > mailing list. Sagi mentioned that we should fix it in the NVMe/RDMA
> > > > > initiator and I'll run his suggestion as well.
> > > >
> > > > Is your device irq affinity linear?
> > >
> > > When it's linear and the balancer is stopped the patch works.
> > >
> > > >
> > > > > BTW, when I run the blk_mq_map_queues it works for every irq affinity.
> > > >
> > > > But its probably not aligned to the device vector affinity.
> > >
> > > but I guess it's better in some cases.
> > >
> > > I've checked the situation before Leon's patch and set all the vetcors
> > > to CPU 0. In this case (I think that this was the initial report by
> > > Steve), we use the affinity_hint (Israel's and Saeed's patches were we
> > > use dev->priv.irq_info[vector].mask) and it worked fine.
> > >
> > > Steve,
> > > Can you share your configuration (kernel, HCA, affinity map, connect
> > > command, lscpu) ?
> > > I want to repro it in my lab.
> > >
> >
> > - linux-4.18-rc1 + the nvme/nvmet inline_data_size patches + patches to
> > enable ib_get_vector_affinity() in cxgb4 + sagi's patch + leon's mlx5
> > patch so I can change the affinity via procfs.
>
> ohh, now I understand that you where complaining regarding the affinity
> change reflection to mlx5_ib_get_vector_affinity and not regarding the
> failures on connecting while the affinity overlaps (that is working good
> before Leon's patch).
> So this is a known issue since we used a static hint that never changes
> from dev->priv.irq_info[vector].mask.
>
> IMO we must fulfil the user wish to connect to N queues and not reduce it
> because of affinity overlaps. So in order to push Leon's patch we must
> also fix the blk_mq_rdma_map_queues to do a best effort mapping according
> the affinity and map the rest in naive way (in that way we will *always*
> map all the queues).
Max,
I have no clue what is needed to do int blq_mq*, but my patch only gave
to users ability reconfigure their affinity mask after driver is loaded.
Thanks
>
> -Max.
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
next prev parent reply other threads:[~2018-07-17 8:58 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-16 8:30 [PATCH mlx5-next] RDMA/mlx5: Don't use cached IRQ affinity mask Leon Romanovsky
2018-07-16 10:23 ` Sagi Grimberg
2018-07-16 10:30 ` Leon Romanovsky
2018-07-16 14:54 ` Max Gurtovoy
2018-07-16 14:59 ` Sagi Grimberg
2018-07-16 16:46 ` Max Gurtovoy
2018-07-16 17:08 ` Steve Wise
2018-07-17 8:46 ` Max Gurtovoy
2018-07-17 8:58 ` Leon Romanovsky [this message]
2018-07-17 10:05 ` Max Gurtovoy
2018-07-17 13:03 ` Steve Wise
2018-07-18 11:38 ` Sagi Grimberg
2018-07-18 14:14 ` Max Gurtovoy
2018-07-18 14:25 ` Steve Wise
2018-07-18 19:29 ` Steve Wise
2018-07-19 14:50 ` Max Gurtovoy
2018-07-19 18:45 ` Steve Wise
2018-07-20 1:25 ` Max Gurtovoy
2018-07-23 16:49 ` Jason Gunthorpe
2018-07-23 16:53 ` Max Gurtovoy
2018-07-30 15:47 ` Steve Wise
2018-07-31 10:00 ` Max Gurtovoy
2018-08-01 5:12 ` Sagi Grimberg
2018-08-01 14:27 ` Max Gurtovoy
2018-08-06 19:20 ` Steve Wise
2018-08-15 6:37 ` Leon Romanovsky
2018-08-16 18:26 ` Sagi Grimberg
2018-08-16 18:32 ` Steve Wise
2018-08-17 16:17 ` Steve Wise
2018-08-17 20:03 ` Sagi Grimberg
2018-08-17 20:17 ` Jason Gunthorpe
2018-08-17 20:26 ` Sagi Grimberg
2018-08-17 21:28 ` Steve Wise
2018-07-24 15:24 ` Steve Wise
2018-07-24 20:52 ` Steve Wise
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180717085831.GB3152@mtr-leonro.mtl.com \
--to=leon@kernel.org \
--cc=dledford@redhat.com \
--cc=jgg@mellanox.com \
--cc=linux-rdma@vger.kernel.org \
--cc=maxg@mellanox.com \
--cc=netdev@vger.kernel.org \
--cc=saeedm@mellanox.com \
--cc=sagi@grimberg.me \
--cc=swise@opengridcomputing.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox