On 14/03/2023 00:16, David Laight wrote:
> From: Laurent Pinchart
>> Sent: 13 March 2023 18:12
>>
>> Hi Benjamin,
>>
>> Thank you for the patch.
>>
>> On Mon, Mar 13, 2023 at 02:59:14PM +0100, Benjamin Gaignard wrote:
>>> Replacing bufs array by a list allows to remove the 32 buffers
>>> limit per queue.
>
> Is the limit actually a problem?
> Arrays of pointers have locking and caching advantages over
> linked lists.
I'm not so keen on using a list either. Adding or deleting buffers will
be an infrequency operation, so using an array of pointers and reallocing
it if needed would be perfectly fine. Buffer lookup based on the index
should be really fast, though.
Why not start with a dynamically allocated array of 32 vb2_buffer pointers?
And keep doubling the size (reallocing) whenever more buffers are needed,
up to some maximum (1024 would be a good initial value for that, I think).
This max could be even a module option.
A simple spinlock is sufficient, I think, to regulate access to the
struct vb2_buffer **bufs pointer in vb2_queue. From what I can see it is
not needed in interrupt context (i.e. vb2_buffer_done).
Regards,
Hans
>
> ...
>>> @@ -1239,8 +1242,12 @@ static inline void vb2_clear_last_buffer_dequeued(struct vb2_queue *q)
>>> static inline struct vb2_buffer *vb2_get_buffer(struct vb2_queue *q,
>>> unsigned int index)
>>> {
>>> - if (index < q->num_buffers)
>>> - return q->bufs[index];
>>> + struct vb2_buffer *vb;
>>> +
>>> + list_for_each_entry(vb, &q->allocated_bufs, allocated_entry)
>>> + if (vb->index == index)
>>> + return vb;
>>> +
>>> return NULL;
>
> You really don't want to be doing that....
>
> There are schemes for unbounded arrays.
> Scanning a linked list isn't a very good one.
>
> David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
