From: Thomas Gleixner <tglx@linutronix.de> To: Christoph Hellwig <hch@lst.de>, John Garry <john.garry@huawei.com> Cc: Ming Lei <ming.lei@redhat.com>, Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@lst.de>, linux-block@vger.kernel.org, linux-nvme@lists.infradead.org, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Bjorn Helgaas <bhelgaas@google.com>, linux-pci@vger.kernel.org, Sagi Grimberg <sagi@grimberg.me>, Daniel Wagner <dwagner@suse.de>, Wen Xiong <wenxiong@us.ibm.com>, Hannes Reinecke <hare@suse.de>, Keith Busch <kbusch@kernel.org> Subject: Re: [PATCH V4 1/3] driver core: mark device as irq affinity managed if any irq is managed Date: Wed, 21 Jul 2021 09:20:00 +0200 [thread overview] Message-ID: <87lf60cevz.ffs@nanos.tec.linutronix.de> (raw) In-Reply-To: <20210719094414.GC431@lst.de> On Mon, Jul 19 2021 at 11:44, Christoph Hellwig wrote: > On Mon, Jul 19, 2021 at 08:51:22AM +0100, John Garry wrote: >>> Address this issue by adding one field of .irq_affinity_managed into >>> 'struct device'. >>> >>> Suggested-by: Christoph Hellwig <hch@lst.de> >>> Signed-off-by: Ming Lei <ming.lei@redhat.com> >> >> Did you consider that for PCI device we effectively have this info already: >> >> bool dev_has_managed_msi_irq(struct device *dev) >> { >> struct msi_desc *desc; >> >> list_for_each_entry(desc, dev_to_msi_list(dev), list) { >> if (desc->affinity && desc->affinity->is_managed) >> return true; >> } >> >> return false; > > Just walking the list seems fine to me given that this is not a > performance criticial path. But what are the locking implications? At the moment there are none because the list is initialized in the setup path and never modified afterwards. Though that might change sooner than later to fix the virtio wreckage vs. MSI-X. > Also does the above imply this won't work for your platform MSI case? The msi descriptors are attached to struct device and independent of platform/PCI/whatever. Thanks, tglx
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Gleixner <tglx@linutronix.de> To: Christoph Hellwig <hch@lst.de>, John Garry <john.garry@huawei.com> Cc: Ming Lei <ming.lei@redhat.com>, Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@lst.de>, linux-block@vger.kernel.org, linux-nvme@lists.infradead.org, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Bjorn Helgaas <bhelgaas@google.com>, linux-pci@vger.kernel.org, Sagi Grimberg <sagi@grimberg.me>, Daniel Wagner <dwagner@suse.de>, Wen Xiong <wenxiong@us.ibm.com>, Hannes Reinecke <hare@suse.de>, Keith Busch <kbusch@kernel.org> Subject: Re: [PATCH V4 1/3] driver core: mark device as irq affinity managed if any irq is managed Date: Wed, 21 Jul 2021 09:20:00 +0200 [thread overview] Message-ID: <87lf60cevz.ffs@nanos.tec.linutronix.de> (raw) In-Reply-To: <20210719094414.GC431@lst.de> On Mon, Jul 19 2021 at 11:44, Christoph Hellwig wrote: > On Mon, Jul 19, 2021 at 08:51:22AM +0100, John Garry wrote: >>> Address this issue by adding one field of .irq_affinity_managed into >>> 'struct device'. >>> >>> Suggested-by: Christoph Hellwig <hch@lst.de> >>> Signed-off-by: Ming Lei <ming.lei@redhat.com> >> >> Did you consider that for PCI device we effectively have this info already: >> >> bool dev_has_managed_msi_irq(struct device *dev) >> { >> struct msi_desc *desc; >> >> list_for_each_entry(desc, dev_to_msi_list(dev), list) { >> if (desc->affinity && desc->affinity->is_managed) >> return true; >> } >> >> return false; > > Just walking the list seems fine to me given that this is not a > performance criticial path. But what are the locking implications? At the moment there are none because the list is initialized in the setup path and never modified afterwards. Though that might change sooner than later to fix the virtio wreckage vs. MSI-X. > Also does the above imply this won't work for your platform MSI case? The msi descriptors are attached to struct device and independent of platform/PCI/whatever. Thanks, tglx _______________________________________________ Linux-nvme mailing list Linux-nvme@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2021-07-21 7:25 UTC|newest] Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-15 12:08 [PATCH V4 0/3] blk-mq: fix blk_mq_alloc_request_hctx Ming Lei 2021-07-15 12:08 ` Ming Lei 2021-07-15 12:08 ` [PATCH V4 1/3] driver core: mark device as irq affinity managed if any irq is managed Ming Lei 2021-07-15 12:08 ` Ming Lei 2021-07-15 12:40 ` Greg Kroah-Hartman 2021-07-15 12:40 ` Greg Kroah-Hartman 2021-07-16 2:17 ` Ming Lei 2021-07-16 2:17 ` Ming Lei 2021-07-16 20:01 ` Bjorn Helgaas 2021-07-16 20:01 ` Bjorn Helgaas 2021-07-17 9:30 ` Ming Lei 2021-07-17 9:30 ` Ming Lei 2021-07-21 0:30 ` Bjorn Helgaas 2021-07-21 0:30 ` Bjorn Helgaas 2021-07-19 7:51 ` John Garry 2021-07-19 7:51 ` John Garry 2021-07-19 9:44 ` Christoph Hellwig 2021-07-19 9:44 ` Christoph Hellwig 2021-07-19 10:39 ` John Garry 2021-07-19 10:39 ` John Garry 2021-07-20 2:38 ` Ming Lei 2021-07-20 2:38 ` Ming Lei 2021-07-21 7:20 ` Thomas Gleixner [this message] 2021-07-21 7:20 ` Thomas Gleixner 2021-07-21 7:24 ` Christoph Hellwig 2021-07-21 7:24 ` Christoph Hellwig 2021-07-21 9:44 ` John Garry 2021-07-21 9:44 ` John Garry 2021-07-21 20:22 ` Thomas Gleixner 2021-07-21 20:22 ` Thomas Gleixner 2021-07-22 7:48 ` John Garry 2021-07-22 7:48 ` John Garry 2021-07-21 20:14 ` Thomas Gleixner 2021-07-21 20:14 ` Thomas Gleixner 2021-07-21 20:32 ` Christoph Hellwig 2021-07-21 20:32 ` Christoph Hellwig 2021-07-21 22:38 ` Thomas Gleixner 2021-07-21 22:38 ` Thomas Gleixner 2021-07-22 7:46 ` Christoph Hellwig 2021-07-22 7:46 ` Christoph Hellwig 2021-07-15 12:08 ` [PATCH V4 2/3] blk-mq: mark if one queue map uses managed irq Ming Lei 2021-07-15 12:08 ` Ming Lei 2021-07-15 12:08 ` [PATCH V4 3/3] blk-mq: don't deactivate hctx if managed irq isn't used Ming Lei 2021-07-15 12:08 ` Ming Lei
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=87lf60cevz.ffs@nanos.tec.linutronix.de \ --to=tglx@linutronix.de \ --cc=axboe@kernel.dk \ --cc=bhelgaas@google.com \ --cc=dwagner@suse.de \ --cc=gregkh@linuxfoundation.org \ --cc=hare@suse.de \ --cc=hch@lst.de \ --cc=john.garry@huawei.com \ --cc=kbusch@kernel.org \ --cc=linux-block@vger.kernel.org \ --cc=linux-nvme@lists.infradead.org \ --cc=linux-pci@vger.kernel.org \ --cc=ming.lei@redhat.com \ --cc=sagi@grimberg.me \ --cc=wenxiong@us.ibm.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.