Eli Cohen wrote:
The following path handles address vectors creation for RDMAoE ports. mlx4 needs the MAC address of the remote node to include it in the WQE of a UD QP or in the QP context of connected QPs. Address resolution is done atomically in the case of a link local address or using service from core/addr.c to do that. mlx4 transport packets were changed too to accomodate for RDMAoE.
Eli, Liran, Sean
As I mentioned over some of the previous threads, doing IP-to-MAC address resolution behind the cover of an IB hardware driver doesn't seem to be the correct approach to me. The address resolution module could do both IP-to-GID and IP-to-MAC.
Or, you can claim that in a similar manner to <dst lid, src lid, sl, mtu, etc> being IB's L2 tuple, since the rdma cm route resolution service does L2 resolution <dst MAC, src MAC, VLAN tag, pbits, mtu, etc> is Ethernet's L2 tuple and route resolution under (over) Ethernet would be resolving that.
All in all, there should be a way to extend the rdma-cm data-structures and concepts such that IBoE would also be supported along with IB and iWARP.
Doing ARP in the IB hardware driver create-address-handle and qp-modify flows, with hiding the MAC inside the driver, simply b/c the rdma-cm wasn't designed to IBoE from day one, and its non trivial to change the cma to support that, isn't the way to go, thoughts?
Or. _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
