Linux-NVME Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: minwoo.im.dev@gmail.com (Minwoo Im)
Subject: [PATCH 2/3] nvme-pci: remove queue_count_ops for write,poll_queues
Date: Sun, 16 Jun 2019 13:51:37 +0900	[thread overview]
Message-ID: <20190616045137.GA5373@minwooim-desktop> (raw)
In-Reply-To: <20190610035219epcms2p152ffea1ffdda63bba9a901dd42979a11@epcms2p1>

On 19-06-10 12:52:19, Minwoo Im wrote:
> 
> > > > > > However, the check is valid, which shouldn't be nop, so could you fix
> > > > > > the check instead of removing it?
> > > > >
> > > > > Hi, Ming.
> > > > >
> > > > > I don't get what you really mean here.   What do you mean "the check is
> > > > > valid"? I don't see any valid checks in queue_count_set(), not just for
> > > > > check for the failure by kstrtoint().  I think current code is just checks
> > > > > the nr_cpus and do nothing after.
> > > > >
> > > > > Instead fixing this check inside of this function, I have posted the next
> > > > > patch in this series to make sure the number of irqs requested not
> > > > > exceed the num_possible_num().
> > > >
> > > > I suggest to cap 'write_queues' or 'poll_writes' to num_possible_num()
> > > > from the beginning, instead of starting with invalid number.
> > >
> > > Ming,
> > >
> > > Thanks for your review :)
> > >
> > > I have already tried to limit the number of queues inside of
> > queue_count_set()
> > > in [1].  But Christoph had suggested to limit the number in
> > nvme_calc_irq_sets()
> > > instead.  It might be my code was not really good at that time, but could
> > you
> > > please have a look at the mail thread below and give some advices for me?
> > >
> > > [1]  http://lists.infradead.org/pipermail/linux-nvme/2019-May/023868.html
> > 
> > Sorry for missing the previous discussion.
> > 
> > IMO, I prefer to the fix in above link. Cause it is the value of
> > kernel_param_ops
> > to make 'write_queue/poll_queue'  correct from the beginning. That is just
> > like OOP's concept in which each method just does one thing. Then we don't
> > need to bother nvme_calc_irq_sets() for verifying/fixing them.
> 
> Christoph,
> 
> What do you think about what Ming's suggested?  I am actually okay with the
> concept that the function just does its own things.
> 
> It would be great if you can give some advices here :)
> 
> Thanks,

(Gentle ping)

Hi Christoph,

Could you please take a look at this patch ?

Thanks,

  reply	other threads:[~2019-06-16  4:51 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-08 18:02 [PATCH 0/3] nvme-pci: adjust irq max_vector to avoid WARN() Minwoo Im
2019-06-08 18:02 ` [PATCH 1/3] nvme-pci: remove unnecessary zero for static var Minwoo Im
2019-06-08 20:27   ` Chaitanya Kulkarni
2019-06-08 18:02 ` [PATCH 2/3] nvme-pci: remove queue_count_ops for write,poll_queues Minwoo Im
2019-06-10  1:51   ` Ming Lei
2019-06-10  2:25     ` Minwoo Im
2019-06-10  2:41       ` Ming Lei
2019-06-10  3:41         ` Minwoo Im
2019-06-10  3:49           ` [PATCH 2/3] nvme-pci: remove queue_count_ops for write, poll_queues Ming Lei
2019-06-10  3:52             ` Minwoo Im
2019-06-16  4:51               ` Minwoo Im [this message]
2019-06-20  6:25                 ` [PATCH 2/3] nvme-pci: remove queue_count_ops for write,poll_queues Christoph Hellwig
2019-06-08 18:02 ` [PATCH 3/3] nvme-pci: adjust irq max_vector using num_possible_cpus() Minwoo Im

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=20190616045137.GA5373@minwooim-desktop \
    --to=minwoo.im.dev@gmail.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