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

[Laine Stump]

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!