On (02/27/09 12:33), Kacheong Poon wrote: > > (which indeed can be changed by setsockopt() on a per socket > basis). Maybe we should remove all ndd params and be done > with it :-)
that would be nice :-) but I agree that some tunables are needed. Note: I'm not necessarily suggesting that we should abolish these, just trying to understand when they are supposed to be useful, and quetioning if they create more confusion than they solve. > to have a knob to turn auto-tuning off in some cases. Just > because something can be changed or auto-tuned on a per > socket basis does not mean that the corresponding ndd params > has zero value. I wasn't suggesting that. However Solaris has an enormous number of tunables compared to other OS'es. It's not clear if we are papering over some problems (or lack of flexibility) in the kernel or just desiging "solutions in search of a problem" to use your own phrase from the earlier tcp discussion. AFAIK equivalents of these tunables do not exist on comparitive OS'es, so I don't know how they deal with the "problem apps" etc. that we are designing against. > Which one of the following you think that are simply wrong > to have such that they can introduce bugs? > - if we want to have an admin knob to fix up the ttl to handle problem apps (and the admin really cannot fix/kill the problem app itself!) why isn't one ttl tunable (for ip) enough? What does it mean to provide ndd tunable for tcp_def_ttl, ip_def_ttl (which is really icmp_err_ttl) and icmp_def_ttl (which is really raw ip ttl)? And what does it mean to provide a tunable for ipv6 unicast hops? >> - icmp_bsd_compat: sounds like something that should >> be a setsockopt, if we want something other than the >> default. Does anyone actually alter the default here? this one is defined as "if 1 (default) the length field in the IP header of received datagrams is adjusted to exclude the length of the IP header. This is compatible with Berkeley derived implementations and is for applications reading raw IP or raw ICMP packets. If 0, the length is not changed." But if the admin sets this to 0, all the existing raw-socket apps that look at the length would be broken! How does it help to have a big button for the whole machine in this case? >> - [ip, tcp, icmp, udp]_wroff_extra- who modifies these >> from defaults? The stack should self-tune these based >> on the ill_phys_addr_length it learns through DLPI. First, I don't know why you would want to do this per ulp, for the whole machine. Second, I don't know why you would want to do this at all: if a driver-writer is working some exotic driver that has a different link-layer length, then they should just provide that link-layer length in the DLPI messages, and IP should adjust suitably. What is the purpose of providing this knob to your average admin who is likely running a mix of ethernet, tunnel, ibd and other interfaces? >> - ip_icmp_return_data_bytes, ip6_icmp_return_data_bytes- >> for IPv4, rfc 1812 (Section 4.3.2.3) says that the icmp >> datagram should contain as much info from the offending >> packet as will fit in 576 bytes. Shouldn't this be >> auto-tuned by the stack? Darren.Reed wrote: > I think Jim was on the money - given that others tend to be including > as much as we can, upto the prescribed limit, so should we. But that > would entail just changing the default, not removing the knob. Actually I don't think Jim Carlson was advocationg on keeping/losing the tunable itself- he was only commenting on "64" being an inadequate default. Do "others" provide a knob for this (not that I am aware of)? --Sowmini
