Kacheong Poon wrote: > Darren Reed wrote: > >> What I read out of all this is that there's not likely to be >> one answer for how all ULP properties are to be handled. > > > I think we should put this in perspective. Those > tunables should not need to be changed in the first > place. So extending the method of changing them to > a per interface basis seems to be finding a problem > for a solution. Instead we should try to eliminate > most of the reasons those tunables need to be changed.
Well, I can't argue with advocating living in a perfect world :) But which project is going to pickup the work of fixing the root causes that you're alluding to here? >> For example, if I were to take the above comment from >> Kacheong and reference TCP timeouts, then it may be >> that picking the "right set" at connect() time when the >> local address is assigned is the right thing to do and not >> when the socket is created or just bound. > > > By "right set," do you mean "right set of TCP timeouts?" Yes. > Usually, it is not recommended to change those TCP timeout > values. And they can be changed on a per connection > basis already. Or do you refer to the previous example > about picking an anonymous port? In that case, we must > pick the port at bind() time. Otherwise, those apps which > do a getsockname() after the bind() will no longer work. So to summarise... - the timeout tunables shouldn't need to exist and therefore don't need further exposure - I'll accept that if there is a commitment and plan to actually fix the root causes. If the root causes aren't going to be fixed, then that undermines not providing them... - then there are non-timeout tunables, such as the "root only" ports, tcp default listen queue length and anonymous port (high/low) as being ones I can name without looking at source code. At present, the proposal is for ipadm to allow things to be tuned with respect to an interface's name. While that makes a certain amount of sense for IP where said properties relate to interfaces, if ipadm is doing TCP/UDP/etc too, the question I'm exploring is what does it mean to tune ULPs at a level that is finer than the instance of IP or is it something that should be avoided? If it is to be avoided then what impact does that have on ipadm output? Can it then meaingfully print out IP and TCP properties together? For all protocols that are managed with ipadm, we might want to give some thought to defining which properties are (or are not) going to be managed by it and if so, to what they can be tied: be it an IP address or a network interface. If managing tuneables on a per-address basis (rather than a per-instance one) is possible, then that opens up the potential for allowing shared-instance zones to have more control over the networking within that zone. Is that complexity worthwhile? It might even be an idea to revisit the tunables we have and consider if we want them as they are or if they should be ...?? Darren
