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!