On Wed, 16 Jun 2021 20:51:41 +0800, Jason Wang <jasowang@xxxxxxxxxx> wrote: > > 在 2021/6/16 下午6:19, Xuan Zhuo 写道: > >>> + * In this way, even if xsk has been unbundled with rq/sq, or a new xsk and > >>> + * rq/sq are bound, and a new virtnet_xsk_ctx_head is created. It will not > >>> + * affect the old virtnet_xsk_ctx to be recycled. And free all head and ctx when > >>> + * ref is 0. > >> This looks complicated and it will increase the footprint. Consider the > >> performance penalty and the complexity, I would suggest to use reset > >> instead. > >> > >> Then we don't need to introduce such context. > > I don't like this either. It is best if we can reset the queue, but then, > > according to my understanding, the backend should also be supported > > synchronously, so if you don't update the backend synchronously, you can't use > > xsk. > > > Yes, actually, vhost-net support per vq suspending. The problem is that > we're lacking a proper API at virtio level. > > Virtio-pci has queue_enable but it forbids writing zero to that. > > > > > > I don’t think resetting the entire dev is a good solution. If you want to bind > > xsk to 10 queues, you may have to reset the entire device 10 times. I don’t > > think this is a good way. But the current spec does not support reset single > > queue, so I chose the current solution. > > > > Jason, what do you think we are going to do? Realize the reset function of a > > single queue? > > > Yes, it's the best way. Do you want to work on that? Of course, I am very willing to continue this work. Although users must upgrade the backend to use virtio-net + xsk in the future, this makes the situation a bit troublesome. I will complete the kernel modification as soon as possible, but I am not familiar with the process of submitting the spec patch. Can you give me some guidance and where should I send the spec patch. Thanks. > > We can start from the spec patch, and introduce it as basic facility and > implement it in the PCI transport first. > > Thanks > > > > > > Looking forward to your reply!!! > > > > Thanks > > > _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
