Sowmini.Varadhan at Sun.COM wrote: >> Darren Reed wrote: >> >> >>> There's every chance that specifying that property, on a per-interface >>> basis, could be meaningful, if/when it is assigned an address. I chose >>> this example for that reason - it doesn't seem like it should be per- >>> interface but it can be applied in that way. >>> > > In theory, a property could be given some semantics per interface, > which is why set-prop takes the -i flag (to allow for this degree > of freedom where needed), but it's not clear to me that this actually > creates useful features in all cases (e.g., allowing the admin > to set ULP properties per interface could allow too many tunables, > which conflicts with the selfg-tuning goal?) >
The tuneables are already there, courtesy of ndd. The problem, today, is that tuning one variable for an application at the system level can have an adverse impact on other apps. Ideally everything would be available via ioctl/setsockopt, but that's not the case. The workaround for that is to (now) put each app in its own exclusive IP instance zone - but that's not a light weight solution. > On (01/14/09 18:02), Kacheong Poon wrote: > >> But is there a reason why a ULP property needs to be tied >> to an IP interface (or address)? Using the example above, >> what is the anonymous port range used by an SCTP association >> bound to both bge1 and bge2? And how about a TCP socket >> bind(INADDR_ANY/0) and then connect()? Which anonymous port >> range does the stack use? Does it make sense for the stack >> to "randomly" pick a local address and use that range even >> when latter on the address is not the preferred one to do >> the connect()? >> > > In addition to all these questions, I would ask similar questions > about ipmp, and how restrictions on inaddr_any/port combinations > complicate the picture. > 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. 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. Or maybe that's just all too dangerous and should be left to instances to solve? Darren
