> I'm not entirely sure I agree....I would have to think about it more, > but the underlying problem I'm concerned with is exactly what I point > out above: what restrictions would we be placing on the hardware that > are artificial and a result of our stack that the hardware itself does > not share? Could the hardware support automatic migration from iWARP > to > RoCE or vice versa if both endpoints supported it? Would that work if > we required two separate ib_devices? Things like that. IMO, in order to create a usable software interface, we will end up defining limitations. The alternative seems to be an endless series of capability bits that expands to millions of combinations, and in the end still won't capture everything. Consider that the existing interfaces already limit what upstream drivers can expose. The primary reason for exposing devices is for apps to associate hardware resources (e.g. CQ and QP) with each other. With software based implementations of roce/iwarp, a device is basically the system. If you connect NICs directly to the CPU, then even separate hardware devices could share state, which could complicate things even more. I'm not sure about Jason's idea of re-defining the PD as a 'protocol domain' (my term), but I think we should seriously consider something similar as an addition to the <device, port> model. I'm still of the opinion that protocol is a property of a QP, not a port. - Sean -- 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
