Re: [RFC PATCH] RDMA/cma: Remove netlink interface of CMA statistics

[Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2020 bytes --]

On Tue, Nov 21, 2017 at 12:14:01AM +0200, Or Gerlitz wrote:
> On Mon, Nov 20, 2017 at 9:41 PM, Jason Gunthorpe <jgg-uk2M96/98Pc@public.gmane.org> wrote:
>
> > Well, I would like to know the issues as well, as I've already said I
> > think they should be described in the commit message.
>
> > But also, at the RFC stage the onus is on other people, particularly
> > people that want to keep the feature, to explain where it is being
> > used and why..
>
> we did it to allow user space track rdma-cm connections through the rdma
> subsystem netlink infra-structure, e.g one can come up with netstat like
> reporting of rdma listeners and connections, this is it!

And after 7 years did anyone use it? The answer is no and it is because
this interface was added without any real user space application which
was supposed to use it.

>
> > We need to decide if we drop the RFC and fix the implementation, apply
> > the the RFC, or add a deprecation printk warning, or something..
>
> right. To my opinion, if there are issues in the implementation, lets fix them,
> I don't see why remove this implementation and replace it with a new one
> that does the same thing.

Just looking at the code without deep dive.

1. Lack of extensibility, in case of desire to add new field to
rdma_cm_id_stats, you will need to throw away this struct and add new
netlink attribute.
2. Device list lock for data retrieval - user can prevent device from
recovery (maybe).
3. It doesn't return device ID !!!!!
4. Completely unscalable by sending message per-struct and not using
netlink nested tables.
5. No check of device identifiers -> returns everything.
4. There is no nlmsg_end at the end of message.

Are you going to fix it?

>
> > Please try to be productive here and concentrate on adding information
> > and not nit-picking the process! We all know removing a uapi is a big
> > deal.
>
> Re usage I provided what I know.

It is wishful thinking, I'm interested in real users and real applications.
Do you know about such?

Thanks

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]