Jens Axboe <ax...@kernel.dk> writes:
> On Fri, Feb 08 2013, Rusty Russell wrote:
>> Paolo Bonzini <pbonz...@redhat.com> writes:
>> > The virtqueue_add_buf function has two limitations:
>> >
>> > 1) it requires the caller to provide all the buffers in a single call;
>> >
>> > 2) it does not support chained scatterlists: the buffers must be
>> > provided as an array of struct scatterlist.
>> >
>> > Because of these limitations, virtio-scsi has to copy each request into
>> > a scatterlist internal to the driver.  It cannot just use the one that
>> > was prepared by the upper SCSI layers.
>> 
>> Hi Paulo,
>> 
>>         Note that you've defined your problem in terms of your solution
>> here.  For clarity:
>> 
>> The problem: we want to prepend and append to a scatterlist.  We can't
>>         append, because the chained scatterlist implementation requires
>>         an element to be appended to join two scatterlists together.
>> 
>> The solution: fix scatterlists by introducing struct sg_ring:
>>         struct sg_ring {
>>                 struct list_head ring;
>>              unsigned int nents;
>>              unsigned int orig_nents; /* do we want to replace sg_table? */
>>                 struct scatterlist *sg;
>>         };
>
> This would definitely be more flexible than the current chaining.
> However:
>
>> The workaround: make virtio accept multiple scatterlists for a single
>>         buffer.
>> 
>> There's nothing wrong with your workaround, but if other subsystems have
>> the same problem we do, perhaps we should consider a broader solution?
>
> Do other use cases actually exist? I don't think I've come across this
> requirement before, since it was introduced (6 years ago, from a cursory
> look at the git logs!).

Thanks Jens.

OK, let's not over-solve the problem then, we'll make a virtio-specific
solution.

Paulo, I'll take your patches once you repost.

Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to