On Tue, Apr 18, 2017 at 06:04:05PM +0200, Jan Tluka wrote:
Tue, Apr 18, 2017 at 04:21:15PM CEST, jtluka(a)redhat.com wrote:
>Few recipes had incorrect devices selected for IRQ pinning.
>Recipe vxlan_multicast included some of the tap devices. As these do not
>have any IRQ assigned it does not make sense to do the pinning on them.
>Recipe novirt_ovs_vxlan selected ovs internal devices instead of physical
>devices. This impacts the performance testing.
>Signed-off-by: Jan Tluka <jtluka(a)redhat.com>
I'm holding push of this patch. There's some issue with the OVS recipe.
Could be a bug in LNST.
I get this error,
Traceback (most recent call last):
File "/usr/bin/lnst-ctl", line 182, in get_recipe_result
res = exec_action(action, nettestctl)
File "/usr/bin/lnst-ctl", line 137, in exec_action
667, in run_recipe
res = self._run_recipe()
685, in _run_recipe
res = self._run_task(task)
733, in _run_task
722, in _run_python_task
module = imp.load_source(name, task_path.resolve())
"/usr/share/lnst/recipes/regression_tests/phase3/novirt_ovs_vxlan.py", line 56,
h1_phy = h1.get_device("if1")
File "/usr/lib/python2.7/site-packages/lnst/Controller/Task.py", line
319, in get_device
raise TaskError("No device with name '%s' found." % str(name))
TaskError: No device with name 'if1' found.
Ah... I know what this is... it's the problem with the duality of nic
related classes on Controller that I created to temporarily solve a
By default we work with the InterfaceAPI objects... these reference
interfaces created directly from the recipe XML - first level under
<interfaces> element. These objects are referenced by the 'id' used in
their respective element.
However, this approach was not usable for internal interfaces of ovs.
To work with them I created a diferent class - DeviceAPI, that isn't
referenced by an 'id' used in the XML file, and instead you either
search by name or interface index used by the remote kernel...
So the Traceback up there is you using the get_device method that
expects a device name and you providint the xml_id instead... So to fix
that issue, just call:
h1_phy = h1.get_interface('if1')
h2_phy = h2.get_interface('if1')
FYI. The InterfaceAPI approach didn't work because of how ovs internal
ports are created and manipulated I was unable to cleanly create
InterfaceAPI objects for them... it would result in several very hard
and ugly hacks, and at that point we were already working on Python
recipes that wouldn't have the same problem. So instead I created the
DeviceAPI objects that are also a dirty hack because they introduce this
broken duality of how to work with NICs, but they were a quick and easy
hack compared to the alternative...