On Wed, May 20, 2015 at 10:13:59AM -0600, Hefty, Sean wrote: > > The other issue is that each caller in the kernel specifies a different > > timeout. Defining this in 1 central place and allowing user space to > > control > > the policy of that timeout is much better than allowing the kernel clients > > to > > specify the timeout as they do now. > > Everything has been randomly hard-coded. IMO, the sa_query module should use > its own timeout value, which it updates based on how fast it actually gets > responses. But that takes too much work, and no one is ever going to write > the code to do this.
I agree. So lets not do this again. > > For the netlink specific problem, I'll propose using a different randomly > hard-coded value as a timeout. Isn't this what we have as the start default to the module parameter? > Then define an 'MRA' type of message that > user space can send to the kernel in order to ask it to wait longer. The > 'set timeout' message could apply to a single request or all future requests. > If we only wanted to the 'all future requests' option, the data value could > be written into a file. This is effectively what we have with the module parameter. > In any case, this pushes the policy of the timeout > value into the hands of the responding daemon. > I'm flexible on the mechanism used. In addition to the module parameter, we discussed sysctl as well as an additional control protocol for configuring the communication. We avoided these to keep the mechanism simple. But since we are going down the path of designing a new protocol I think it is reasonable to have some "control" packets there. Ira -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
