All of lore.kernel.org
 help / color / mirror / Atom feed
From: willy@linux.intel.com (Matthew Wilcox)
Subject: TODO list 2011-12-09
Date: Fri, 9 Dec 2011 16:37:40 -0500	[thread overview]
Message-ID: <20111209213740.GJ14291@linux.intel.com> (raw)


Here's the current TODO list that I have.  Thuoght it might be useful
for people who are wonder what still needs doing.  If you have anything
else (public) that you'd like to see changed in the driver, let me know
and I'll add it to the list.

Also, if you happen to be working on any of these features, feel free to
let me know so I can make a note.  Keith's working on #2, which prompted
me to actually post this list.

While these items are numbered ... it's not a strict priority list.

 1. Write an error handler
 2. Add a character device for /dev/nvmeN for devices with no visible
    namespaces (Keith Busch)
 3. Submit Async Event Request commands
 4. Better CPU -> queue mapping
 5. Submit multiple partial I/Os with a single doorbell write
 6. Handle block/VM queue congestion
 7. Make kthread per CPU
 8. Use the async mechanism for namespaces
 9. MODULE_PARM_DESC for module parameters (Reported-by: Randy Dunlap)
10. Handle ioremap returning NULL
11. Add support for SCSI ioctls
12. Decide on a sysfs representation for NVMe devices
13. Figure out how to support the Range Type partitioning scheme
14. Use a mempool for nvme requests
15. Call completion handlers at submission time
16. Experiment with interrupt mitigation settings
17. Let user tune interrupt mitigation through sysfs
18. Use an ida for the 'instance' code
19. Implement DSM Deallocate (ie trim)
20. Get a bi_rw incompressible bit, set it in ecryptfs & dm_crypt
21. Write PCI error handling code
22. PCI Suspend/Resume
23. Handle CPU hotplug (allocate/free queues)
24. Add support for data integrity (DIX)
25. Investigate amortising SQ and CQ doorbell writes
26. Experiment with NUMA locality (SQ / CQ local to CPU or to device)
27. Sanity check for namespace count?
28. make_request may sleep -- should the NVMe driver's do that?
29. Allow the Arbitration feature to be adjusted
30. Implement Security Send / Receive
31. Investigate other DSM fields
32. Implement NVMe Power Management
33. Allow for controlling Volatile Write Cache
34. Expose Write Atomicity to block layer
35. Implement Software Progress
36. Remove 'process_cq did something' message
37. Add tracepoint support
38. Allow maximum transfer size and queue depth to be controlled

             reply	other threads:[~2011-12-09 21:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-09 21:37 Matthew Wilcox [this message]
2011-12-12 18:59 ` TODO list 2011-12-09 Kong, Kwok
2011-12-12 20:47   ` Matthew Wilcox
2011-12-13  1:38     ` Kong, Kwok
2011-12-12 19:25 ` Kong, Kwok
2011-12-12 19:28 ` Kong, Kwok

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=20111209213740.GJ14291@linux.intel.com \
    --to=willy@linux.intel.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 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.