From: Keith Busch <[email protected]>
To: Kanchan Joshi <[email protected]>
Cc: Chaitanya Kulkarni <[email protected]>,
Kanchan Joshi <[email protected]>,
"[email protected]" <[email protected]>, "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [RFC 3/3] nvme: wire up support for async passthrough
Date: Fri, 5 Mar 2021 11:41:33 +0900 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+1E3rLvrC4s2o3qDgHfRWN0JhnB5ZacHK572kjP+-5NmOPBhw@mail.gmail.com>
On Thu, Mar 04, 2021 at 04:31:11PM +0530, Kanchan Joshi wrote:
> On Thu, Mar 4, 2021 at 3:14 AM Chaitanya Kulkarni
> <[email protected]> wrote:
> >
> > On 3/2/21 23:22, Kanchan Joshi wrote:
> > > + if (!ioucmd)
> > > + cptr = &c;
> > > + else {
> > > + /*for async - allocate cmd dynamically */
> > > + cptr = kmalloc(sizeof(struct nvme_command), GFP_KERNEL);
> > > + if (!cptr)
> > > + return -ENOMEM;
> > > + }
> > > +
> > > + memset(cptr, 0, sizeof(c));
> > Why not kzalloc and remove memset() ?
>
> Yes sure. Ideally I want to get rid of the allocation cost. Perhaps
> employing kmem_cache/mempool can help. Do you think there is a better
> way?
I'll need to think on this to consider if the memory cost is worth it
(8b to 64b), but you could replace nvme_request's 'struct nvme_command'
pointer with the struct itself and not have to allocate anything per IO.
An added bonus is that sync and async handling become more the same.
next prev parent reply other threads:[~2021-03-05 2:41 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20210302160907epcas5p4d04ab7c4ef4d467302498f06ed656b24@epcas5p4.samsung.com>
2021-03-02 16:07 ` [RFC 0/3] Async nvme passthrough Kanchan Joshi
[not found] ` <CGME20210302161000epcas5p3ec5c461a8eec593b6d83a9127c7fec4f@epcas5p3.samsung.com>
2021-03-02 16:07 ` [RFC 1/3] io_uring: add helper for uring_cmd completion in submitter-task Kanchan Joshi
[not found] ` <CGME20210302161005epcas5p23f28fe21bab5a3e07b9b382dd2406fdc@epcas5p2.samsung.com>
2021-03-02 16:07 ` [RFC 2/3] nvme: passthrough helper with callback Kanchan Joshi
2021-03-03 7:52 ` Chaitanya Kulkarni
2021-03-04 11:13 ` Kanchan Joshi
2021-03-05 4:14 ` Chaitanya Kulkarni
2021-03-05 10:40 ` Kanchan Joshi
[not found] ` <CGME20210302161010epcas5p4da13d3f866ff4ed45c04fb82929d1c83@epcas5p4.samsung.com>
2021-03-02 16:07 ` [RFC 3/3] nvme: wire up support for async passthrough Kanchan Joshi
2021-03-03 7:34 ` Chaitanya Kulkarni
2021-03-04 11:01 ` Kanchan Joshi
2021-03-04 22:59 ` Chaitanya Kulkarni
2021-03-05 1:46 ` Jens Axboe
2021-03-05 2:41 ` Keith Busch [this message]
2021-03-05 10:44 ` Kanchan Joshi
2021-03-05 13:17 ` hch
2021-03-03 7:35 ` Chaitanya Kulkarni
2021-03-04 10:55 ` Kanchan Joshi
2021-03-05 13:22 ` hch
2021-03-03 7:37 ` Chaitanya Kulkarni
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=20210305024133.GD32558@redsun51.ssa.fujisawa.hgst.com \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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