On Thu, Feb 09, 2017 at 09:55:18PM +0000, Parav Pandit wrote:
> This means our GID cache will have two GID entries with different netdev.
When you load this into the GID cache you need to have four unique
entries for the MAC vlans:
(MAC-B, VLAN1, IP-1)
(MAC-C, VLAN1, IP-2)
(MAC-D, VLAN2, IP-1)
(MAC-E, VLAN2, IP-3)
And unique entries for IPs on the VLAN interfaces
(MAC-A, VLAN1, LL-IP for eth0.vlan1)
(MAC-A, VLAN2, LL-IP for eth0.vlan2)
And unique entries for the base netdevice:
(MAC-A, UNTAGGED, LL-IP for eth0)
All of these are unique keys in the GID cache.
> Now when ib_wc arrives for it, it will not have mac address in it,
> but we will have VLAN. Which means we can only reach upto
> eth0.vlan1.
As I said before, you fundamentally cannot support macvlan on hardware
that does not provide the dmac or equivalent in the wc. As Matan said,
those IPs should never be added to the GID table in the first place.
> If I seach gid cache purely based on the GID, vlan id, and netdev of
> eth0.vlan1 there won't a match in GID table.
You'd never search the GID table with a netdev as part of the key.
But yes, if the hardware provides only (VLAN_ID, GID) then, by
definition, that hardware only supports DMAC == MAC-A and the gid
table search is (MAC-A, VLAN_ID, GID) and will not match any MACVLAN
entries.
This correct because the hardware does not support macvlan.
> for_each_lower_netdev_of_vlan(slave_ndev, list) {
> ifaddr = search_ifaddr(netdev, gid);
This search is basically what ipvlan does.
It is completely wrong to replace the macvlan semantics with ipvlan
semantics way down in the offload world. If the admin intended to use
ipvlan then they would have done that.
You must stop trying to add fake support for macvlan on hardware that
cannot support it.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
