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@xxxxxxxx> 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:
signature.asc
Description: PGP signature
