> On 18 Oct 2016, at 16:25, Marc-André Lureau <mlur...@redhat.com> wrote:
> 
> Hi Felipe
> 
> ----- Original Message -----
>> Hello,
>> 
>>> On 18 Oct 2016, at 10:24, Marc-André Lureau <marcandre.lur...@redhat.com>
>>> wrote:
>>> 
>>> <...>
>>> 
>>> diff --git a/contrib/libvhost-user/libvhost-user.h
>>> b/contrib/libvhost-user/libvhost-user.h
>>> 
>>> <...>
>>> 
>>> +#define VHOST_MAX_NR_VIRTQUEUE 8
>>> +#define VIRTQUEUE_MAX_SIZE 1024
>> 
>> I think that the maximum number of VQs should be 1024 to match Qemu's.
>> 
>> http://git.qemu.org/?p=qemu.git;a=blob;f=include/hw/virtio/virtio.h;h=b913aac45589449bcc5d8161651332f4b0d69c7f;hb=HEAD#l55
> 
> That would make the VuDev structure quite big. We may want to set the nr of 
> max queues in vu_init() instead, and allocate it there. I think this is 
> rather a current limitation, but does not prevent iterating from there.

Well, it depends what we call "quite big". The only thing that depends on that 
is:

> struct VuDev {
> <...>
>     VuVirtq vq[VHOST_MAX_NR_VIRTQUEUE];
> <...>

And VuVirtq is 96 bytes in size (x86_64). So we're really talking about 768 
bytes vs 96 KiB.

Actually, you can bring it down to 88 bytes by...

> typedef struct VuRing {
>     unsigned int num;
>     struct vring_desc *desc;
>     struct vring_avail *avail;
>     struct vring_used *used;
>     uint64_t log_guest_addr;
>     uint32_t flags;

... moving "flags" just below "num". Allows gcc to compact the struct better.

> } VuRing;


I'd rather fix this kind of thing sooner than later, but it's ultimately up to 
you.

Felipe

Reply via email to