On Thu, Apr 28, 2016 at 11:23:33PM +0000, Hefty, Sean wrote: > > This isn't dismissing them as silly, it is a pragmatic need in the > > core code that everything associated with a PD have a minimum standard > > of uniformity - and it is very clear that includes things like the > > iwarp special cases and the particular format of the AHs. > > I was referring to Christoph's comment "that multi-protocol devices > are indeed as silly as they seem". Maybe we're using different > meanings for the term 'device'. I'm referring to the physical > hardware. Oh. I think the rest of this thread uses device to refer to a 'struct ib_device'. > > Fundamentally we have the wrong model for such hardware. When a PD is > > created it should set the 'protocol' and select the compatible member > > ports that belong to the PD. Cap tests and so forth should be done > > against the PD, not a port or a device. > > I agree that the model is wrong. But this is the first email I've > read (and I skip reading a lot) mentioning the PD. The last time this came up we talked about the right place to apply the 'cap' tests and the idea of using the PD or QP was briefly discussed. > My concern is that the discussion mentioned removing multi-protocol > support completely, rather than improving it. No, the topic is to remove the port num from the cap tests. This is clarifying the current capability of the core code, which is that a struct ib_device must have certain uniformity across all ports. The port_num is totally wrong headed and is not the way to support some future multi-protocol hardware within a single struct ib_device. > I was referring to the sharing of resources (e.g. CQs, MRs) across > different protocols on the same device. Hum, can those even realistically be shared? Eg an iWarp and IB MRs have very different semantics, both in terms of the key and how the permission model works. IIRC CQs had some subtle differences too, and of course extracting an address from a WC is very different. This is why I bring up the PD as a 'narrower' container for the required uniformity. Jason -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
