Darren Reed wrote:
> Well, I can't argue with advocating living in a perfect world :)
Why is doing some RFEs "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?
Over the years, we did a number of RFEs for this kind of
things. I don't believe that this needs a project... As
a simple example related to the current discussion, some
customers wanted to change the timeout values on a per
connection basis many years ago. So we did a simple RFE
for that.
I don't see the need to have a project to implement
something we "think" will be tuned by some "unknown"
customers. As I mentioned before, those tunables are not
supposed to be changed normally. They are there to handle
exceptional cases without the need to ship a new binary to
solve a customer's issue. If the need to change a tunable
becomes normal, we can do a RFE to solve the case.
What project are you thinking we need to do? And what
is the problem you think we need to solve?
> 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...
What do you mean by "root causes?" What exactly is the
problem you referred to above? The need to change some
timeout values? There is no root cause as there is really
not a problem. A customer wants to do something special
in their own private network. So they don't want the
default timeout values. There is no fancy reason.
> - 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.
Why does someone want to change the above tunables on a
per interface/address basis? Is this a normal need?
> 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?
I think so far those people who have participated in this
discussion think that there is really no such need at this
moment.
> If it is to be avoided then what impact does that have on ipadm
> output?
I don't quite understand. I guess each ipadm command,
say show-address, has its own output. In the current
document Sowmini sent out, I don't see why the output of
ipadm needs to be "standardized" so that IP interface is
a "must have" output for every ipadm commands.
> Can it then meaingfully print out IP and TCP properties together?
What is the problem you see here?
> 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?
I think this is not the same problem as ULP tunables on
a per interface/address basis. The above is a shared-instance
zone question. Should we allow such zone to have its own
set of tunables? Allowing that does not mean that we need
to have tunables on a per interface/address basis. It should
be discussed in another thread if people really think that
it should be done.
> 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 ...??
I think Sowmini has been doing that for quite some time
already.
--
K. Poon.
kacheong.poon at sun.com
