[email protected] wrote:
I'm mid-way through the list of ndd tunables (see
updates to http://cr.opensolaris.org/~sowmini/ndd.html
which also briefly describes these parameters)
and came across some items that don't look like they
belong in ndd at all- these look like good candidates
for setsockopts, or things that ought to be auto-tuned
by the stack.
Just a general comment. If we follow the above reasoning,
we probably should not have ndd params like, tcp_recv_hiwat
(which indeed can be changed by setsockopt() on a per socket
basis). Maybe we should remove all ndd params and be done
with it :-)
IMHO, ndd params are there for unexpected things which a
customer can patch it immediately without waiting for a
binary fix. And I also don't believe auto-tuning is a cure
for all, as it can have bugs and cannot handle situations
not envisioned at development time. In fact, it is prudent
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.
Having said the above, I agree that some ndd params probably
need to be checked out to see if they are actually wrong.
Which one of the following you think that are simply wrong
to have such that they can introduce bugs?
I'd like to find out if anyone's using these, or can
think of reasons why these should belong in ndd:
- setting ip/tcp/udp/icmp TTL through ndd:
Do we really want to change the default ttl for all
ip/tcp/udp/icmp packets? Esp when there are socket options
like IP_TTL, IPV6_UNICAST_HOPS, IP_MULTICAST_TTL for this?
(See also 5046705)
We have ip_def_ttl, ip6_def_hops, tcp_ipv4_ttl,
tcp_ipv6_hoplimit, icmp_ipv4_ttl, icmp_ipv6_hoplimit,
udp_ipv4_ttl, udp_ipv6_hoplimit, ip_broadcast_ttl.
Aren't IP_TTL, IPV6_UNICAST_HOPS, IP_MULTICAST_TTL
sufficient?
- 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?
- [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.
- 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?
any thoughts or insights into the reason these are
ndd tunables would be appreciated!
Note that the above list is *not* exhaustive- there
may be more ndd "tunables" that would be better dealt
with through other means.
--Sowmini
_______________________________________________
networking-discuss mailing list
[email protected]
--
K. Poon.
[email protected]
_______________________________________________
networking-discuss mailing list
[email protected]
