On Sat, Jul 01, 2023 at 04:27:23PM +0000, Chuck Lever III wrote: > > > > On Jul 1, 2023, at 12:24 PM, Tom Talpey <tom@xxxxxxxxxx> wrote: > > > > On 6/29/2023 11:16 AM, Chuck Lever wrote: > >> From: Chuck Lever <chuck.lever@xxxxxxxxxx> > >> We would like to enable the use of siw on top of a VPN that is > >> constructed and managed via a tun device. That hasn't worked up > >> until now because ARPHRD_NONE devices (such as tun devices) have > >> no GID for the RDMA/core to look up. > >> But it turns out that the egress device has already been picked for > >> us -- no GID is necessary. addr_handler() just has to do the right > >> thing with it. > >> Suggested-by: Jason Gunthorpe <jgg@xxxxxxxxxx> > >> Signed-off-by: Chuck Lever <chuck.lever@xxxxxxxxxx> > >> --- > >> drivers/infiniband/core/cma.c | 15 +++++++++++++++ > >> 1 file changed, 15 insertions(+) > >> diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c > >> index 889b3e4ea980..07bb5ac4019d 100644 > >> --- a/drivers/infiniband/core/cma.c > >> +++ b/drivers/infiniband/core/cma.c > >> @@ -700,6 +700,21 @@ cma_validate_port(struct ib_device *device, u32 port, > >> if ((dev_type != ARPHRD_INFINIBAND) && rdma_protocol_ib(device, port)) > >> goto out; > >> + /* Linux iWARP devices have but one port */ > > > > I don't believe this comment is correct, or necessary. In-tree drivers > > exist for several multi-port iWARP devices, and the port bnumber passed > > to rdma_protocol_iwarp() and rdma_get_gid_attr() will follow, no? > > Then I must have misunderstood what Jason said about the reason > for the rdma_protocol_iwarp() check. He said that we are able to > do this kind of GID lookup because iWARP devices have only a > single port. > > Jason? I don't know alot about iwarp - tom does iwarp really have multiported *struct ib_device* models? This is different from multiport hw. If it is multiport how do the gid tables work across the ports? Jason
