Re: [PATCH V3 5/6] RDMA CM: Save Owning PID

[Or Gerlitz <ogerlitz-hKgKHo2Ms0FWk0Htik3J/w@public.gmane.org>]

Jason Gunthorpe wrote:
> Nir Muchtar wrote:
> It is tied to the ucma_fops FD (ie /dev/rdma_cm, aka the event
> channel), which when closed calls ucma_free_ctx which calls rdma_destroy_id. 
> Processes that can access that FD can control the RDMA CM IDs associated with it.
> The only case where this is not true is in the kernel, and in that
> instance the PID is meaningless - you'd be much better off exporting
> the name of the module that allocated the RDMA CM ID.

Jason,

I'd like to strengthen the point Nir was trying to make with real-life examples

1. the Linux iscsi initiator - has a daemon named iscsid which opens all the iscsi connections where a connection is over specific transport - e.g iscsi/tcp, iser, iscsi offloads etc. iscsid is talking with the kernel iscsi stack through netlink (...) and in that framework iser connections are started from the **kernel** i.e directly with the rdma-cm and not through librdmacm. With Nir's patches we'd like to be able to track these connections, e.g now I can see through the iscsi tools that I have four sessions (=connections), two of them with iscsi/tcp and two with iser, but I must use a dedicated tool/stack (the iscsi one) for that, wheres if I had a way generic way to track all the connections  made through the rdma-cm things will be much easier.

> # netstat -ntp
> Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name
> tcp        0      0 192.168.20.1:45858          192.168.20.222:3260         ESTABLISHED 26793/iscsid
> tcp        0      0 192.168.20.1:45859          192.168.20.222:3260         ESTABLISHED 26793/iscsid

no sign for the iser connections, has to use dedicated tool

> # iscsiadm -m session
> iser: [76] 192.168.20.222:3260,1 iqn.iser.A
> tcp: [77] 192.168.20.222:3260,1 iqn.tcp.D
> iser: [79] 192.168.20.222:3260,1 iqn.iser.B
> tcp: [80] 192.168.20.222:3260,1 iqn.tcp.C

2. sdp - the code runs in the kernel, same story, the connections are not tracked, a dedicated "sdpnetstat" tool has to be used. Connections (sockets) are tied to processes and will be best if reported through generic netlink interface

3. rds - again, kernel level rdma-cm, here connections are not tied to processes, but no reporting as of today and dedicated "rds-info" tool has to be used.

I'm sure there are (nfs rdma) and will be more examples for kernel level usage of the rdma-cm for which the pid field is helpful, 

Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html