>Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> writes: > >>> We have written a new block driver for our AHCI based PCIe SSDs. The >>> main objective of our product is providing high performance. Traffic >>> through OS storage stack is not to able fully utilize the device's >>> capabilty. To improve the traffic to the device and hence >>> showcase/utilize the device's capability, we have come up with this new >>> block driver. This driver includes >>> * utilize device's increased queue depth >>> * workaround for hardware errata >>> >>> We want to get this driver into kernel tree to support the device out of >>> the box. Attached this driver as a patch for latest kernel. We would >>> like to get your comments, and also open for discussion. >> >> The kernel starting point would be that we have an AHCI driver. If you >> need workarounds for hardware errata then they can go into it and that is >> fine. We support NCQ so we can use the queue depths. If there are >> extensions then the AHCI driver can be enhanced. > >Given the highly parallel nature of these parts, I wouldn't be surprised >if the ahci queue depth of 31 is one of the main bottlenecks. Can you >think of a way to extend the ahci driver in this manner to accommodate >devices like this one? > >Cheers, >Jeff Correct, the device appears as a single AHCI port device but supports a queue depth of 128. It does this by muxing the registers from port 1,2,3 onto port 0. I think this might be possible by creating device specific port_start, qc_issue and change_queue_depth functions. --jordan hargrave Dell Enterprise Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
