How about making openwrt's bridge support VEPA?

[daiaji]

The bridge currently used by openwrt does not support VEPA, which seems to make it almost impossible for SR-IOV VF to connect with ordinary devices.

https://www.sealingtech.com/blog/sr-iov-and-promiscuous-mode/
https://forums.unraid.net/topic/103323-how-to-using-sr-iov-in-unraid-with-1gb10gb40gb-network-interface-cards-nics/

[brada4]

Yes, in ethernet 8021q tagged VLANs cannot talk to untagged ports preferably. You either need switch to untag them or each end node willing to communicate on tagged VLAN to decode them. Wire protocol is same with SR-IOV aka VEPA and (installed by default) 8021q VLANs

[daiaji]

macvlan seems to be in a similar dilemma, which makes both SR-IOV and macvlan in virtualization scenarios difficult to use due to the lack of IEEE 802.1Qbg switches.

[brada4]

Qbg means catcing virtual port id on newly communicating 8021q VLAN-s and wiring it to correct switched VLAN according to some centralized configuration database.

You cannot have 2 uses of 8021q tagged incoming packet. It goes to virtual function in hardware, or to macvlan or bridge in kernel, not to all.

Your references deal with virtual function mapped to VLAN-s only, not about practically nonexistant wire signalling.

[jow-]

This query is too unspecific to act upon. I suggest writing a detailed feature proposal (e.g. what are the equivalent minimum require steps on a standard Linux distribution to achieve the desired result) in the OpenWrt Forum feature request section.

[daiaji]

To be precise, I don't know much about it, and the information mentioned in this issue is all I know.
https://lists.linuxfoundation.org/pipermail/virtualization/2009-August/013491.html
There appears to have been an attempt to add VEPA support to the bridge, but this patch does not seem to have been accepted.

[brada4]

PDF file does not constitute any acceptable kernel code.
There is wild misconception behind bundling wire protocol, i.e saying on VLAN that it is virtual port ABC in a way similar to CDP and friends. and the qemu machinery attaching virtual function - PCIE sub-device to that VLAN. At that high end i can barely imagine LACP not being used and actually having single virtual function to pass-through to the guest. Best is to trust bridge per VLAN and hope for future lowlevel offloads. Thats kind of what vmware or hyperv does nowadays.