On Wed, 2017-05-31 at 13:34 -0500, Steve Wise wrote: > > > I would hate to introduce an iwarp regression vs solving your issue w/o > > > reverting. If I recall, the flow control is need so as to not drop messages > > > flowing from the kernel to the iwpmd. I'm not sure how that could be fixed > > > in the user daemon? > > > > Assume that netlink is unreliable and set socket timeout. > > It seems that netlink is becoming more and more a message API between kernel and > user. Wouldn't everyone benefit from make it reliable? And I think we can > certainly provide blocking/reliable mode as an option to be used only by those > subsystems that require it. Sorry Steve but I'm not sure that's a good idea. Netlink uses fixed size buffers for sending messages to user space. Making netlink reliable means making the kernel wait if the buffer is full. That would introduce the possibility of a kernel deadlock if the user space application hangs. I don't think we want that. BTW, are you aware netlink reports buffer overflows to user space through the ENOBUFS error code? Any user space software that reads from a netlink socket should check the error code returned by recv() and resynchronize the state if recv() fails with ENOBUFS. I'm writing here "should" because there are several examples of user space software that doesn't do this correctly. Bart.-- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
