On Tue, 2017-08-01 at 12:52 -0500, Chien Tin Tung wrote: > On Tue, Aug 01, 2017 at 05:28:54PM +0000, Bart Van Assche wrote: > > On Tue, 2017-08-01 at 12:14 -0500, Chien Tin Tung wrote: > > > On Tue, Aug 01, 2017 at 04:55:09PM +0000, Bart Van Assche wrote: > > > > Yes, I had read these e-mails but I do not agree with all of what was written > > > > in these e-mails. I'm not sure whether you are aware of the original design > > > > goal of the netlink mechanism? It was designed on purpose to be unreliable > > > > such that sending information from the kernel to user space would never block. > > > > > > Please show me a feference to Netlink design document/email on mailing list > > > that specifically disallowed this? > > > > As you probably know kernel developers do not write design documents. But there > > is plenty of evidence on the web that the netlink mechanism was designed to be > > unreliable. A quote from a Linux Journal article from 2005 > > (http://www.linuxjournal.com/article/7356): "Netlink is asynchronous because, > > as with any other socket API, it provides a socket queue to smooth the burst > > of messages." > > So what happens when the queue is full? you can fail at that point or you > can choose the 1-shot retry with timeout as we have done. What is _wrong_ > with the 1-shot retry? Why is the one-shot retry necessary? What aspect of the portmapper design makes this one-shot retry necessary? Why is this one-shot retry only necessary for the portmapper and not for any other Netlink client? 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
