On Mon, Mar 28, 2011 at 6:21 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > Merge struct sci_base_controller into scic_sds_controller, and also factor > the two types of state machine handlers into one function. While we're at > it also remove lots of duplicate incorrect kerneldoc comments for the state > machine handlers. > > Signed-off-by: Christoph Hellwig <hch@xxxxxx> Conversion looks correct to me and smoketests fine, applied. > + * XXX: How does the io_tag parameter get assigned to the io request? This is an area where I think we can make some further simplifications. Currently the core supports a concept of lldd-assigned and core-assigned io tags (the latter is currently being used and is set at scic_sds_request_constructed_state_start_handler time). The Linux driver will never have use for more than one assignment mode and to me it is awkward to have separate hw-task-context (tci pool index) and lldd-request-object (dma_pool_alloc) allocation domains. One allocation can handle the request object, tci, and tag allocation. So this looks like: 1/ Convert to mvsas style pre-allocation of request objects so a single number space handles available requests, task contexts, and tags. Since libsas drivers do not queue we will never be in a situation of needing to oversubscribe requests to hw-task-contexts. Although I have found that the sci_pool interface is faster than a bitmap by a wide margin for randomly arriving completions. It does tradeoff space and simple detection of double-free conditions. If acceptable that probably wants to be a generic kernel facility unless there is an existing ring-buffer method for tracking unique numbers? 2/ Reuse the request object allocation index as the tag/tci and move sequence number management to the request allocation routine. Essentially this is the next level of detail on the isci_request/scic_sds_request unification. -- Dan -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
