From: Christoph Hellwig <hch@lst.de>
To: Logan Gunthorpe <logang@deltatee.com>
Cc: Sagi Grimberg <sagi@grimberg.me>,
Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>,
Christoph Hellwig <hch@lst.de>,
linux-nvme@lists.infradead.org,
Douglas Gilbert <dgilbert@interlog.com>
Subject: Re: [PATCH] nvmet-passthru: Cleanup nvmet_passthru_map_sg()
Date: Fri, 16 Oct 2020 15:57:59 +0200 [thread overview]
Message-ID: <20201016135759.GA4685@lst.de> (raw)
In-Reply-To: <b798e7f6-0afc-551c-f6d9-f7900b400137@deltatee.com>
On Thu, Oct 15, 2020 at 12:40:52PM -0600, Logan Gunthorpe wrote:
> > But those are entirely unrelated to the bio size. BIO_MAX_PAGES is
> > 256, so with 4k pages and assuming none can't be merged that is 1MB,
> > while max_segments/max_hw_sectors could be something much larger.
>
> Isn't it constrained by max_segments which is set to NVME_MAX_SEGS=127
> (for PCI)... less than BIO_MAX_PAGES...
nvmet-passthrough is not limited to work on PCIe controllers. And even
if it did relying on an implicit limit like that is a time bomb. I
have work pending for one of the next merge windows to lift that limit
for example, and I would not have thought that nvmet-passthrough
relies on it in any way.
> Would the NVME driver even work if max_segments was greater than
> BIO_MAX_PAGES? Correct me if I'm wrong, but it looks like
> blk_rq_map_sg() will only map one bio within a request. So there has to
> be one bio per request by the time it hits nvme_map_data()...
blk_rq_map_sg maps the bio chain. Take a look at the for_each_bio
loop in __blk_bios_map_sg.
> If you want me to send a patch to future proof the MDTS limit with
> BIO_MAX_PAGES, I can do that, but it doesn't look like it will have any
> effect right now unless big things change.
Yes, please do.
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2020-10-16 13:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-09 23:18 [PATCH] nvmet-passthru: Cleanup nvmet_passthru_map_sg() Logan Gunthorpe
2020-10-13 22:26 ` Sagi Grimberg
2020-10-13 22:38 ` Douglas Gilbert
2020-10-14 0:16 ` Chaitanya Kulkarni
2020-10-14 0:20 ` Logan Gunthorpe
2020-10-14 0:25 ` Chaitanya Kulkarni
2020-10-14 15:47 ` Logan Gunthorpe
2020-10-15 7:56 ` Christoph Hellwig
2020-10-15 16:01 ` Logan Gunthorpe
2020-10-15 17:24 ` Douglas Gilbert
2020-10-15 18:01 ` Christoph Hellwig
2020-10-15 18:40 ` Logan Gunthorpe
2020-10-16 13:57 ` Christoph Hellwig [this message]
2020-10-16 16:49 ` Logan Gunthorpe
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=20201016135759.GA4685@lst.de \
--to=hch@lst.de \
--cc=chaitanya.kulkarni@wdc.com \
--cc=dgilbert@interlog.com \
--cc=linux-nvme@lists.infradead.org \
--cc=logang@deltatee.com \
--cc=sagi@grimberg.me \
/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 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.