Rusty Russell <rusty@xxxxxxxxxxxxxxx> wrote on 09/09/2010 05:44:25 PM: > > > > This seems a bit weird. I mean, the driver used vdev->config-> find_vqs > > > to find the queues, which returns them (in order). So, can't you put > > this > > > into your struct send_queue? > > > > I am saving the vqs in the send_queue, but the cb needs > > to locate the device txq from the svq. The only other way > > I could think of is to iterate through the send_queue's > > and compare svq against sq[i]->svq, but cb's happen quite > > a bit. Is there a better way? > > Ah, good point. Move the queue index into the struct virtqueue? Is it OK to move the queue_index from virtio_pci_vq_info to virtqueue? I didn't want to change any data structures in virtio for this patch, but I can do it either way. > > > Also, why define VIRTIO_MAX_TXQS? If the driver can't handle all of > > them, > > > it should simply not use them... > > > > The main reason was vhost :) Since vhost_net_release > > should not fail (__fput can't handle f_op->release() > > failure), I needed a maximum number of socks to > > clean up: > > Ah, then it belongs in the vhost headers. The guest shouldn't see such > a restriction if it doesn't apply; it's a host thing. > > Oh, and I think you could profitably use virtio_config_val(), too. OK, I will make those changes. Thanks for the reference to virtio_config_val(), I will use it in guest probe instead of the cumbersome way I am doing now. Unfortunately I need a constant in vhost for now. Thanks, - KK -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
