Re: [PATCH 02/12] IB/cma: pass the port number to ib_create_qp

[Jason Gunthorpe <jgunthorpe@obsidianresearch.com>]

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