> On Jun 10, 2023, at 12:38 PM, Tom Talpey <tom@xxxxxxxxxx> wrote: > > On 6/10/2023 8:05 AM, Jason Gunthorpe wrote: >> On Fri, Jun 09, 2023 at 04:49:49PM -0400, Tom Talpey wrote: >>> On 6/7/2023 3:43 PM, 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. 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. >>>> >>>> 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); >>> >>> This might work, but I'm skeptical of the conditional. There's nothing >>> special about iWARP that says a GID should come from the outgoing device >>> mac. And, other protocols without IB GID addressing won't benefit. >> The GID represents the source address, so it better come from the >> outgoing device or something is really wrong. >> iWARP gets a conditional because iwarp always has a single GID, other >> devices do not work that way. > > Not sure I follow. TCP is routable so it can use multiple egress ports. > That same routing means an incoming packet bearing an appropriate local > address will be accepted on any port. An siw virtual device, for example, is paired with one particular network i/f. I'm not sure that "multiple egress ports" is applicable. I would think this is also the case with a device-offloaded iWARP implementation: the egress device is always the i/f on the offload card. > So still, I don't think this an iWARP property per se. Agreed, it's not particular to the iWARP protocol. But it does seem to be particular to the entire class of iWARP protocol implementations on Linux. Adding a comment about this distinction would certainly be apropos. > It's coming from > the transport and its addressing. I'd hope that this can be gleaned from > something other than "it's iWARP, cma needs to do ...". I could add another flag somewhere to indicate this property of a device. I expect only Linux iWARP devices would set it, though, so would it really add much value? Do you have a recommendation for where to home such a flag? Would it be a fixed device property, or something that would be set dynamically during earlier steps of address resolution? Again, it feels like something that would be set iff rdma_protocol_iwarp() is true... -- Chuck Lever
