On 12/08/2015 12:13 AM, Max Khon wrote:
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".
You are right. Sorry about my confusion, I was going too much by memory
instead of the actual code :)
OK so yes, we currently have iovec count in tcmu_cmd_entry.req based
upon the cmd's incoming scatterlists' lengths. Maybe this was left over
from some previous version, or let the code be simpler. But as you can
see we have one iovec per scatterlist but they all end up describing
parts of one contiguous range in the data area (except for the
buffer-wrap case), so we *could* be describing the buffers with max 2
iovecs. But we are not at the moment.
When we move to something fancier like we have been discussing, I
believe the code will be simpler if we no longer do iovecs like this,
but have just one for each contiguous range in the data area that we need.
I understand that you suggest to consolidate all scatterlists into a
fixed number of continuous allocation blocks. I will look into this.
Sounds great, please let me know if anything else is in need of explanation.
Regards -- Andy
--
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
