Re: [libvirt PATCH v8 0/3] Ignore EPERM on implicit clearing of VF VLAN ID

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2/3/22 10:52 AM, Michal Prívozník wrote:
On 2/3/22 15:45, Laine Stump wrote:
On 2/2/22 1:04 PM, Michal Prívozník wrote:

Laine, any thoughts?

I somehow thought this had already been pushed, so I was surprised when
it showed up again :-/

I think the only issue I had before was that I thought the new unit
tests were more testing the test setup than the actual code, but Dan
convinced me otherwise.

So I'm fine with this change.


Cool, pushed now.

A newly discovered (but pre-existing, so non-consequential to these
patches) problem associated with vlans is that we don't differentiate
between "set vlan 0" and "don't set any vlan", which I hadn't even
considered before, until this BZ came up:

  https://bugzilla.redhat.com/2035726

(The reporter is trying to use <tag id='-1'/> to "unset" the vlan tag
for an interface)


Ah, but the bug report is for openvswitch port profile, so that's doubly
unrelated :-)

Yes and now. The original report was about openvswitch ports, but then the reporter also tried things with hostdev SRIOV devices and macvtap passthrough devices (with varying results). I'm sure that whatever is done to fix it will be deeply intertwined and complicated by the current topic (since the whole point of these patches is that smartnics want/need to just leave the entire vlan tag thing alone) :-)

Additionally, Dmitrii's change might make it possible to easily/simply fix the case of updating vlan tag for existing macvtap passthrough and hostdev SRIOV VFs (since we can now set the vlan tag without doing anything else). So for once there is an unintended *good* side effect!




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux