Re: New -udm?

[Mike Christie <mikenc@us.ibm.com>]

Mike Christie wrote:
> Lars Marowsky-Bree wrote:
> 
>> On 2005-04-10T18:14:44, Dave Olien <dmo@osdl.org> wrote:
>>
>>
>>> You're correct.  I'll rewrite it on Thursday this week.
>>> I'll use the same methods Lars used in the dm-emc.c
>>
>>
>>
>> Note that dm-emc.c also would need to pre-allocate it's requests, but
>> doesn't right now :/
>>
>> Pre-allocating the requests sucks: Either we pre-allocate for _every_
>> path we might potentially need to send the request down on, or fix up
>> the request for the path we sent it down on (which would require us to
>> use internal knowledge about the req structs we're not supposed to
>> have).
> 
> 
> what is wrong with what you have now where you utilize the queue/path's 
> mempool by doing a blk_get_request with GFP_WAIT? 

or were you talking about the page for data backing which does not have 
a mempool like the bios (not per queue though) and requests.

Is that "fix up the
> request..." comment meaning that you do not like to access the request 
> structure for that code, or was it meaning that you have one request 
> that is shared across paths and it needs to be cleaned up for reuse.
> 
> I think the hw_handlers setting up the requests is not so fun. Maybe the 
> block layer scsi_ioctl code could be reworked a little so that it could 
> set some of that up for us since it is very similar. My hw handler was 
> basically cutting and pasting of that code with some large 
> simplifcations. I am working on a Target Port Group handler that is 
> again cutting and pasting more code.
> 
>>
>> Good solutions solicited ;-)
>>
>>
>> Sincerely,
>>     Lars Marowsky-Brée <lmb@suse.de>
>>
> 
> 
> -- 
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
>