On Thu, Dec 08, 2016 at 09:29:32AM +0000, Liran Liss wrote: > > Well in that case, we should work toward getting rid of 'struct ib_device' - it is > > the cause of so much of this trouble. A port-focused model like the netstack uses > > is overall saner.. > > > > We are discussing 2 separate issues: > (1) Whether a device can support multiple protocols > (2) Multi-port devices, optionally with different link types. > > I think that we all agree that (1) will be needed for future > devices, We all agree future hardware devices will support multiple protocols, but I don't think there is any agreement so far on how to model that, or what 'struct ib_device' means in such a world. As I said, I'd like to get rid of it if we use a QP centric model to solve this problem. > and that different QPs might be running different protocols. This > means that supported protocols need to be device capabilities, No, they are QP capabilities, add new APIs to work with and query QP related things and stop using the device for anything. > have today in the kernel. There are several devices that implement > (2), which follows directly from the specification. The model for > these devices is not going to change. Again, no, the specification for multiport devices does not contemplate different addressing formats, so the one driver that did this went off spec in a badly thought out manner and left us this mess. > kernel). Doing so at the device level seems to be more aligned with > how most future devices would be implemented. However, I won't rule > out multi-port devices so soon. When the transport is offloaded to > HW, it makes sense to conduct HA between ports within the domain of > a single device. It is a QP thing if we go down Sean's suggestion, so add QP related queries to get the information. I have no idea how to model HA in this world - presumably when you add an AH to a QP it will refuse to do it if the implied HA model isn't supported. But, I'm not sure how well the QP model works when talking about HA/APM.. > In any case, this has nothing to do with 'struct ib_device', which > represents a device that handles packet processing internally and > exposes transport endpoints to applications. We need to make sense of what 'struct ib_device' is to figure out how to solve these problems because we have multiple different definitions running around concurrnatly in the stack - that is why it doesn't work today to have more than one protocol on a struct ib_device. So, yes, it actually has everything to do with 'struct ib_device'.. 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
