Attach VMs to DPDK-controlled NICs. As https://github.com/oVirt/ovirt-site/pull/1070 describes, currently the user is expected to configure DPDK on each host manually, use the still-experimental OVS switch-type for the cluster, define VM with custom properties, and pin it to a specific host, since migration is not yet supported. Under these limitations, the user can enjoy high performance networking in their VM guest.
Irit, what is the status of the feature?
fully works, needs some more performance tweaks and maybe worth adding an auxiliary installation script. No code change in vdsm is needed.
(In reply to Irit Goihman from comment #2) > fully works, needs some more performance tweaks and maybe worth adding an > auxiliary installation script. No code change in vdsm is needed. Can we move it to MODIFIED?
OK from my side, Dan do you agree?
DPDK is all about performance. And we still do not have a use case where what we have done actually improves performance. Without a measurable performance improvement this does not deserve to be declared as an ovirt-4.2 feature.
(In reply to Dan Kenigsberg from comment #5) > DPDK is all about performance. And we still do not have a use case where > what we have done actually improves performance. Without a measurable > performance improvement this does not deserve to be declared as an ovirt-4.2 > feature. Irit - please provide or work with QE to provide performance numbers? Dan - the code is in, so this should be in MODIFIED state, unless we know of additional work that needs to be done. If it doesn't work, we can remove it from docs, or whatever is needed.
Without a numerical proof, I fear that most of the work is still ahead of us. I have opened this RFE only for its documentational value, and I do not see the merit of including it in 4.2 in its current state. I prefer to postpone it to 4.3 over moving it to MODIFIED.
(In reply to Dan Kenigsberg from comment #7) > Without a numerical proof, I fear that most of the work is still ahead of > us. I have opened this RFE only for its documentational value, and I do not > see the merit of including it in 4.2 in its current state. I prefer to > postpone it to 4.3 over moving it to MODIFIED. ACK - moved to 4.3. If we can do anything by the end of October, I'm fine with bringing it back to 4.2.