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]

 



> On Tue, Apr 19, 2016 at 09:49:03PM +0300, Sagi Grimberg wrote:
> >
> > >>>The new RW API will need this.
> > >>>
> > >>>Signed-off-by: Christoph Hellwig <hch@xxxxxx>
> > >>>Reviewed-by: Bart Van Assche <bart.vanassche@xxxxxxxxxxx>
> > >>>Tested-by: Steve Wise <swise@xxxxxxxxxxxxxxxxxxxxx>
> > >>
> > >>I'm not opposed to this change but traditionally QPs are bound to a
> > >>device not to a single port.
> > >
> > >Right, this was done because rdma_protocol_iwarp takes a port number.
> > >
> > >I think we discussed this once, the core code doesn't actually support
> > >different protocols on different ports, so the port_num argument to
> > >rdma_protocol_iwarp is redundant.
> > >
> > >This all starts to look really goofy when multi-port APM is used and
> > >the QP's port number changes dynamically at runtime. (I have some
> > >experimental patches that do that), I'd rather see all the port_num
> > >stuff in this series go away. :(
> >
> > HCH and I complained about this per-port distinction in several private
> > conversations. I'd really love to see it go away too.
> 
> I'm in support of eliminating them. One protocol per device.
>

Ditto.
 
> IB APM hard requires those semantics, and that reflects the reality of
> all the drivers today.
> 
> Nothing more is required than sending a patch, IHMO..
> 

I've been trying to sift through the original threads regarding
rdma_protocol_iwarp() and friends.  I couldn't find anybody advocating hard that
the protocol/transport type should be per port.
 
I think this thread has Doug stating it really should be per-device and static.
Doug, correct me if I'm wrong...

https://lkml.org/lkml/2015/4/10/612

Steve.

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