On 11/04/2016 02:50 AM, Yuanhan Liu wrote: > On Thu, Nov 03, 2016 at 10:11:43PM +0100, Maxime Coquelin wrote: >> >> >> On 11/03/2016 05:09 PM, Yuanhan Liu wrote: >>> Queue allocation should be done once, since the queue related info (such >>> as vring addreess) will only be informed to the vhost-user backend once >>> without virtio device reset. >>> >>> That means, if you allocate queues again after the vhost-user negotiation, >>> the vhost-user backend will not be informed any more. Leading to a state >>> that the vring info mismatches between virtio PMD driver and vhost-backend: >>> the driver switches to the new address has just been allocated, while the >>> vhost-backend still sticks to the old address has been assigned in the init >>> stage. >>> >>> Unfortunately, that is exactly how the virtio driver is coded so far: queue >>> allocation is done at queue_setup stage (when rte_eth_tx/rx_queue_setup is >>> invoked). This is wrong, because queue_setup can be invoked several times. >>> For example, >>> >>> $ start_testpmd.sh ... --txq=1 --rxq=1 ... >>> > port stop 0 >>> > port config all txq 1 # just trigger the queue_setup callback again >>> > port config all rxq 1 >>> > port start 0 >>> >>> The right way to do is allocate the queues in the init stage, so that the >>> vring info could be persistent with the vhost-user backend. >>> >>> Besides that, we should allocate max_queue pairs the device supports, but >>> not nr queue pairs firstly configured, to make following case work. >> I understand, but how much memory overhead does that represent? > > We are allocating max queue pairs the device supports, but not the > virtio-net spec supports, which, as you stated, would be too much. Oh, ok. In this case this is good to me.
Thanks, Maxime
