On Tue, Oct 23 2007 at 21:15 +0200, Matthew Wilcox <matthew@xxxxxx> wrote:
> On Tue, Oct 23, 2007 at 08:46:52PM +0200, Boaz Harrosh wrote:
>>> We could also add an alloc_bidi_cmnd/destroy_bidi_cmnd to the shost
>>> template. Presumably most commands won't be bidi for any given host,
>>> so it'd be a waste of space to allocate them for all commands.
>> Well no one really knows. The OSD scsi devices I use are bidi only commands
>> (OK not only, 99%). The rest are not yet defined. (Like raid arrays that do
>> write-return-XOR)
>
> What's the usage scenario though? Do we envisage one scsi_host being
> dedicated to OSD, or do we envisage OSDs being one component on a FC
> network? I suspect the latter, which leads me to want to do something
> like ...
>
Yes, like I have OSD devices on the other side of an iscsi transport.
So there can be other none OSD devices on the iscsi initiator. It's
a per device thing.
> struct qla_cmnd {
> char *sp;
> unsigned int compl_status;
> unsigned int resid_len;
> unsigned int scsi_status;
> unsigned int actual_snslen;
> unsigned int entry_status;
> }
>
> struct qla_bidi_cmnd {
> struct bidi_cmnd;
> struct qla_cmnd;
> }
>
> struct qla_cmnd {
> struct scsi_cmnd;
> struct qla_cmnd;
> }
>
> But then this requires us to have a bidi_queue_command. That might not
> be such a bad idea anyway ...
>
The current solution is pretty simple, we hang an extra scsi_data_buffer on
cmd->request->next_rq->special and allocate it when needed from a new cache_mem_pool
of bidi scsi_data_buffer's. Since for an OSD device all Cmnds are bidi, I thought
of saving that extra allocation. But it looks like the current model is not working
for my case, so I'll keep it as it is now.
You can see an example of this here:
http://www.bhalevy.com/open-osd/download/bidi_2.6.23/0004-SCSI-bidi-support.patch
Thanks
Boaz
-
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
