> > We can't. its per major. But the scsi layer does its own request merging
> > too (clustering code).
>
> Sure, but as I see it the scsi layer will never attempt to cluster
> requests larger than what the ll_rw_block currently permits (without
> help).
>
> I do like the idea of having devices control their own merging,
> it allows for greater flexibility. But current 2.3 is just not
> very clear on what is handled by ll_rw_block and what the devices
> do themselves.
Yes, I probably need to document this some.
The basic idea is that a request_queue_t can contain some function
pointers that are used to assist with the merging process. There are
essentially two functions - q->merge_fn() is used if ll_rw_blk wants to know
if it can merge a new block into an existing request, and
q->merge_requests_fn() is used to test to see if combining two separate
requests would result in a single request that is too large or not.
Both of these functions should return 1 if it is acceptable for
ll_rw_blk to perform the merge, and should return 0 if it is not acceptable.
As things stand, the queue merge functions are also responsible for
maintaining the req->nr_segments field in the event that the number changes
as a result of the merge. ll_rw_blk also touches it some - when it creates
a brand new request, it initializes the field to 1.
For drivers that don't have any special requirements, these function
pointers will be NULL (as it stands currently). In such cases ll_rw_blk has
it's own default methods for deciding these matters.
The code got kind of muddled when I resolved some of the merge conflicts
in the 2.3.xx kernels. I believe that the DAC960 driver tried to implement
a means to limit the number of scatter-gather segments, and that still
exists in parallel to the stuff I added which gives a driver complete
control over what gets merged. Someone really needs to go back in and
retrofit this scheme into the DAC 960 and thereby simplify the ll_rw_blk
code a little more. Ideally this would be someone who has one of the
suckers - I could only do it blind and hope that I got it right. A change
like this would have the added advantage of eliminating one of those tables
indexed by major number.
Another enhancement that I can think of would be to update
blk_init_queue() to initialize merge_fn and merge_requests_fn to point to
default handlers in ll_rw_blk.c. In this way, the function pointers should
never be NULL, and the code paths would be cleaner. Such a change would
also make it easier to retrofit DAC960 for that matter.
-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
