Andy,
>> The problem is that iovec[] size depends on se_cmd scatterlists length
>> (basically se_cmd->t_bidi_data_nents + se_cmd->t_data_nents).
>> How big/long these can be?
>>
>> That's why I tried to re-use scatterlists to keep data ring allocation
>> information (as I was not quite sure how to keep the information about
>> variable sized scatterlist in a fixed-size tcmu_cmd).
>>
>> Do you have any ideas?
>
>
> iovec[] size does *not* depend on scatterlists length, it depends on how
> many contiguous sections of the data area we need. Because we are copying
> and consolidating at the same time all the scatterlist buffers into the data
> area. With the current circular allocator, iovec len will usually be 1, and
> will only be 2 if the data buffer was split across the end of the data area.
I was referring to the current code in target-pending master where the
dependency exists:
tcmu_queue_cmd_ring():
/*
* Must be a certain minimum size for response sense info, but
* also may be larger if the iov array is large.
*
* iovs = sgl_nents+1, for end-of-ring case, plus another 1
* b/c size == offsetof one-past-element.
*/
base_command_size = max(offsetof(struct tcmu_cmd_entry,
req.iov[se_cmd->t_bidi_data_nents + se_cmd->t_data_nents + 2]),
sizeof(struct tcmu_cmd_entry));
alloc_and_scatter_data_area():
for_each_sg(data_sg, sg, data_nents, i) {
...
(*iov)->iov_len = copy_bytes;
(*iov)->iov_base = ...;
(*iov_cnt)++;
(*iov)++;
...
}
So it is not 1 or 2 but "se_cmd->t_bidi_data_nents + se_cmd->t_data_nents + 1".
Are you referring to some other branch in target-pending where you do
consolidation?
I understand that you suggest to consolidate all scatterlists into a
fixed number of continuous allocation blocks. I will look into this.
Max
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
