On 04/08/2015 07:02 PM, Hefty, Sean wrote: [snip] >> >> The wrapper make sense, but do we have the guarantee that IBoE port won't >> be used for AF_IB address? I just can't locate the place we filtered it >> out... > > I can't think of a reason why IBoE wouldn't work with AF_IB, but I'm not sure if anyone has tested it. The original check would have let IBoE through. When I suggested checking for IB transport, I meant the actual transport protocol, which would have included both IB and IBoE. Got it :-) > >>>> @@ -700,8 +700,7 @@ static int cma_ib_init_qp_attr(struct [snip] > >>>> id_priv->id.route.addr.dev_addr.dev_type = >>>> - (rdma_port_get_link_layer(cma_dev->device, p) == >>>> IB_LINK_LAYER_INFINIBAND) ? >>>> + (rdma_transport_ib(cma_dev->device, p)) ? >>>> ARPHRD_INFINIBAND : ARPHRD_ETHER; >>> >>> This wants the link layer, or maybe use cap_ipoib. >> >> Is this related with ipoib only? > > ARPHDR_INFINIBAND is related to ipoib. In your next update, maybe go with tech_ib. I don't know the status of ipoib over iboe. Will be in next version :-) Regards, Michael Wang > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
