A number of modules may require traffic from some unicast or multicast addresses that are filtered by hw when in non promisc / non allmulti mode.
Always running in promisc / allmulti is certainly possible, though it means receiving unwanted traffic.
But relying on promisc / allmulti may hide some network misconfiguration, or some other network equipment misbehaving, as grout would handle traffic that it should not in theory.
The request here is to add per iface lists of unicast and mcast addresses for which traffic is expected.
For a dpdk port backed interface, such lists will be associated with calls to rte_eth_dev_mac_addr_add, rte_eth_dev_mac_addr_del for unicast and rte_eth_dev_set_mc_addr_list. If adding a unicast/mcast address fails, then fallback would be to enable promisc / allmulti.
Associated with this, there is a need to track if enabling promisc/allmulti is a consequence of those unicast/mcast addresses or a request from the user (think of the case when the user enables promisc/allmulti via grcli, and later disables it).
The Linux kernel solution is to maintain a count of promisc / allmulti users (reflected by the "promiscuity" / "allmulti" counters one can find with "ip -s -d link").
A number of modules may require traffic from some unicast or multicast addresses that are filtered by hw when in non promisc / non allmulti mode.
Always running in promisc / allmulti is certainly possible, though it means receiving unwanted traffic. But relying on promisc / allmulti may hide some network misconfiguration, or some other network equipment misbehaving, as grout would handle traffic that it should not in theory.
The request here is to add per iface lists of unicast and mcast addresses for which traffic is expected.
For a dpdk port backed interface, such lists will be associated with calls to rte_eth_dev_mac_addr_add, rte_eth_dev_mac_addr_del for unicast and rte_eth_dev_set_mc_addr_list. If adding a unicast/mcast address fails, then fallback would be to enable promisc / allmulti.
Associated with this, there is a need to track if enabling promisc/allmulti is a consequence of those unicast/mcast addresses or a request from the user (think of the case when the user enables promisc/allmulti via grcli, and later disables it). The Linux kernel solution is to maintain a count of promisc / allmulti users (reflected by the "promiscuity" / "allmulti" counters one can find with "ip -s -d link").