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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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.

> For instance, even if a hardware device can run rocee and iwarp
> concurrently over a single port, today we absolutely must have
> different struct ib_devices for the same physical port to be able to
> plug that into the core stack.
> 
> 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.  My concern is that the discussion mentioned removing multi-protocol support completely, rather than improving it.

> Fixing that is major surgery, and having cap tests to the port is not
> helping clarify the current situation.
> 
> > Restricting all ports on a device to support all protocols is
> > different than restricting a device to supporting a single protocol,
> > and it affects more than APM.
> 
> What else is there that is cross port in verbs?

I was referring to the sharing of resources (e.g. CQs, MRs) across different protocols on the same device.
--
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



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux