From: Aaron Williams <awilliams@marvell.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [EXT] Re: [PATCH 1/1] nvme: Fix PRP Offset Invalid
Date: Wed, 21 Aug 2019 22:06:36 +0000 [thread overview]
Message-ID: <9553102.Vhu4Oq2qB3@flash> (raw)
In-Reply-To: <CAEUhbmVnnropG01KAVsB8cHSYXffkYHj_dhi_N9G-5oRR66eeQ@mail.gmail.com>
Hi Bin,
On Wednesday, August 21, 2019 8:23:50 AM PDT Bin Meng wrote:
> Hi Aaron,
>
> On Wed, Aug 21, 2019 at 7:26 PM Aaron Williams <awilliams@marvell.com>
wrote:
> > Hi Bin,
> >
> > I submitted another patch via git. Hopefully it went through. I'm new to
> > trying to get email to work with GIT since until now nobody in my group
> > has
> > had access to a working SMTP server so I'm still learning how to use git
> > send- email.
> >
> > -Aaron
> >
> > On Wednesday, August 21, 2019 12:55:59 AM PDT Bin Meng wrote:
> > > External Email
> > >
> > > ----------------------------------------------------------------------
> > > Hi Aaron,
> > >
> > > On Wed, Aug 21, 2019 at 8:34 AM Aaron Williams <awilliams@marvell.com>
> >
> > wrote:
> > > > When large writes take place I saw a Samsung
> > > > EVO 970+ return a status value of 0x13, PRP
> > > > Offset Invalid. I tracked this down to the
> > > > improper handling of PRP entries. The blocks
> > > > the PRP entries are placed in cannot cross a
> > > > page boundary and thus should be allocated on
> > > > page boundaries. This is how the Linux kernel
> > > > driver works.
> > > >
> > > > With this patch, the PRP pool is allocated on
> > > > a page boundary and other than the very first
> > > > allocation, the pool size is a multiple of
> > > > the page size. Each page can hold (4096 / 8) - 1
> > > > entries since the last entry must point to the
> > > > next page in the pool.
> > >
> > > Please write more words in a line, about 70 characters in a line.
> > >
> > > > Signed-off-by: Aaron Williams <awilliams@marvell.com>
> > > > ---
> > > >
> > > > drivers/nvme/nvme.c | 9 ++++++---
> > > > 1 file changed, 6 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
> > > > index 7008a54a6d..ae64459edf 100644
> > > > --- a/drivers/nvme/nvme.c
> > > > +++ b/drivers/nvme/nvme.c
> > > > @@ -75,6 +75,8 @@ static int nvme_setup_prps(struct nvme_dev *dev, u64
> > > > *prp2,>
> > > >
> > > > int length = total_len;
> > > > int i, nprps;
> > > > length -= (page_size - offset);
> > > >
> > > > + u32 prps_per_page = (page_size >> 3) - 1;
> > > > + u32 num_pages;
> > >
> > > nits: please move these 2 above the line "length -= (page_size -
> > > offset);"
> >
> > Done.
> >
> > > > if (length <= 0) {
> > > >
> > > > *prp2 = 0;
> > > >
> > > > @@ -90,15 +92,16 @@ static int nvme_setup_prps(struct nvme_dev *dev,
> > > > u64
> > > > *prp2,>
> > > >
> > > > }
> > > >
> > > > nprps = DIV_ROUND_UP(length, page_size);
> > > >
> > > > + num_pages = (nprps + prps_per_page - 1) / prps_per_page;
> > >
> > > use DIV_ROUND_UP()
> >
> > Done
> >
> > > > if (nprps > dev->prp_entry_num) {
> > >
> > > I think we should adjust nprps before the comparison here.
> > >
> > > nprps += num_pages - 1;
> > >
> > > > free(dev->prp_pool);
> > > >
> > > > - dev->prp_pool = malloc(nprps << 3);
> > > > + dev->prp_pool = memalign(page_size, num_pages *
> > > > page_size);
> > >
> > > Then we need only do: dev->prp_pool = memalign(page_size, nprps << 3)?
> >
> > We can't use nprps << 3 because if the prps span more than a single page
> > then we lose a prp per page.
>
> Looks you missed my comment above.
>
> If we adjust nprps by "nprps += num_pages - 1", then we don't lose the
> last prp per page.
This would work.
>
> Mallocing num_pages * page_size exceeds the real needs. We should only
> allocate the exact prp size we need.
This is true, but if we were forced to increase it, there may be a good chance
that it may need to be increased again. I do not see an issue in allocating
based on the number of pages required rather than the number of bytes. At
most, 4K-8 will be wasted. On the other hand, this can prevent additional
memalign calls from being called.
>
> > > > if (!dev->prp_pool) {
> > > >
> > > > printf("Error: malloc prp_pool fail\n");
> > > > return -ENOMEM;
> > > >
> > > > }
> > > >
> > > > - dev->prp_entry_num = nprps;
> > > > + dev->prp_entry_num = ((page_size >> 3) - 1) *
> > > > num_pages;
> > >
> > > and no need to change this line, but we need change the while (nprps) {}
> > > loop.
> > >
> > > > }
> > > >
> > > > prp_pool = dev->prp_pool;
> > > >
> > > > @@ -791,7 +794,7 @@ static int nvme_probe(struct udevice *udev)
> > > >
> > > > }
> > > > memset(ndev->queues, 0, NVME_Q_NUM * sizeof(struct nvme_queue
> > > > *));
> > > >
> > > > - ndev->prp_pool = malloc(MAX_PRP_POOL);
> > > > + ndev->prp_pool = memalign(1 << 12, MAX_PRP_POOL);
> > >
> > > I think we need use ndev->pagesize instead of (1 << 12), but
> > > ndev->pagesize is initialized in nvme_configure_admin_queue(), so we
> > > need move the initialization of ndev->pagesize out of that function
> > > and do it before the memalign() here.
> > >
> > > > if (!ndev->prp_pool) {
> > > >
> > > > ret = -ENOMEM;
> > > > printf("Error: %s: Out of memory!\n", udev->name);
>
> Regards,
> Bin
next prev parent reply other threads:[~2019-08-21 22:06 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-21 0:34 [U-Boot] [PATCH 1/1] nvme: Fix PRP Offset Invalid Aaron Williams
2019-08-21 7:55 ` Bin Meng
2019-08-21 11:23 ` [U-Boot] [PATCH 1/1][nvme] " Aaron Williams
2019-08-21 11:23 ` [U-Boot] [PATCH] nvme: " Aaron Williams
2019-08-21 11:26 ` [U-Boot] [EXT] Re: [PATCH 1/1] " Aaron Williams
2019-08-21 15:23 ` Bin Meng
2019-08-21 22:06 ` Aaron Williams [this message]
2019-08-22 1:38 ` Bin Meng
2019-08-22 9:12 ` [U-Boot] [PATCH] " Aaron Williams
2019-08-22 9:17 ` Aaron Williams
2019-08-22 14:25 ` Bin Meng
2019-08-22 18:05 ` [U-Boot] [PATCH v3 1/1] " Aaron Williams
2019-08-22 18:05 ` [U-Boot] [PATCH v3 0/1] nvme: Fix invalid PRP Offset Aaron Williams
2019-08-22 18:05 ` [U-Boot] [PATCH v3 1/1] nvme: Fix PRP Offset Invalid Aaron Williams
2019-08-23 3:24 ` Bin Meng
2019-08-23 3:37 ` [U-Boot] [PATCH v4 " Aaron Williams
2019-08-23 3:37 ` [U-Boot] [PATCH v4 0/1] " Aaron Williams
2019-08-23 3:37 ` [U-Boot] [PATCH v4 1/1] " Aaron Williams
2019-08-27 0:19 ` Tom Rini
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=9553102.Vhu4Oq2qB3@flash \
--to=awilliams@marvell.com \
--cc=u-boot@lists.denx.de \
/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