> On Jun 7, 2023, at 3:43 PM, Chuck Lever <cel@xxxxxxxxxx> 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. addr_handler() just has to do the right thing with it. > > Tested with siw and qedr, both initiator and target. > > Suggested-by: Jason Gunthorpe <jgg@xxxxxxxxxx> > Signed-off-by: Chuck Lever <chuck.lever@xxxxxxxxxx> > --- > drivers/infiniband/core/cma.c | 3 +++ > 1 file changed, 3 insertions(+) > > This of course needs broader testing, but it seems to work, and it's > a little nicer than "if (dev_type == ARPHRD_NONE)". > > One thing I discovered is that the NFS/RDMA server implementation > does not deal at all with more than one RDMA device on the system. > I will address that with an ib_client; SunRPC patches forthcoming. Or maybe not. I'm looking at cma_iw_acquire_dev(). Where is the listen_id_priv->id.port_num field supposed to be initialized? > diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c > index 56e568fcd32b..c9a2bdb49e3c 100644 > --- a/drivers/infiniband/core/cma.c > +++ b/drivers/infiniband/core/cma.c > @@ -694,6 +694,9 @@ cma_validate_port(struct ib_device *device, u32 port, > if (!rdma_dev_access_netns(device, id_priv->id.route.addr.dev_addr.net)) > return ERR_PTR(-ENODEV); > > + if (rdma_protocol_iwarp(device, port)) > + return rdma_get_gid_attr(device, port, 0); > + > if ((dev_type == ARPHRD_INFINIBAND) && !rdma_protocol_ib(device, port)) > return ERR_PTR(-ENODEV); > > > -- Chuck Lever
