On 9/30/2017 7:34 PM, Yuanhan Liu wrote:
On Thu, Sep 30, 2017 at 12:53:00PM +0000, Jianfeng Tan wrote:
On 9/30/2017 4:23 PM, Yuanhan Liu wrote:
On Thu, Sep 28, 2017 at 01:55:59PM +0000, Jianfeng Tan wrote:
+static int
new_device(int vid)
{
struct rte_eth_dev *eth_dev;
@@ -610,6 +685,8 @@ new_device(int vid)
_rte_eth_dev_callback_process(eth_dev, RTE_ETH_EVENT_INTR_LSC,
NULL, NULL);
+ share_device(vid);
+
Another question is, have you considered/tested the case when the VM
changes the qeueue number later?
Yes, that is a covered test case, we use ethtool to increase the
combined queue number; see cover letter for detail.
Sorry I missed that!
However, I'm not quite sure I understood you:
Step 5: enable multi queue in VM1 and VM2.
$ ethtool -L ethX combined 2
Note in this test case, only queue 1, i.e., secondary process can process
packets. To use queue 1, basically, we can run command like:
$ taskset -c 1 <commands>
Do you mean the secondary can't rx/tx pkts from/to the 2nd queue?
And you are asking the user to add "taskset -c 1" each time he
wants to run a command inside the VM?
No, the result is because the logic of this example, symmetric_mp, is
that primary process works on the queue pair 0; and secondary process
works on queue pair 1. And because of the limitation we mentioned
earlier, primary process can process the virtqueue but cannot kick the
queue pair 0 (wrong callfd). But secondary process can work on both
queue pair 0 and 1 in theory, unfortunately, cannot find an existing
example to test that.
Thanks,
Jianfeng
--yliu
