The table insert and delete functions are already fully serialized
on dp_mutex (and genl_mutex), so there's no need for them to use
additional spinlocks.
Before, we didn't really synchronize this at all. Now, when we want
to destroy the ofX device, we stop the transmit path and wait for
in-progress transmissions to finish.
There was little point in taking the dp_mutex farther down in the
code than dp_genl_openflow, since that function is already completely
serialized by genl_rcv across the genl_mutex. We could get rid of
dp_mutex completely, except that we still need it to serialize timeout.
These code paths are fully protected by the Generic Netlink genl_mutex,
which is taken by genl_rcv() that calls dp_genl_openflow(), so there is
no need for them to take the rcu_read_lock.
We can't guarantee uniqueness of ip_id versus the host's, screwing up
fragment reassembly, so prevent fragmentation and use an all-zeros
ip_id. RFC 791 doesn't say we can do this, but Linux does the same
thing for DF packets, so it must not screw anything up.
The secure channel, in discovery mode, wants to enable TCP connections
by default only if SSL has not been configured. This function allows
it to do that.
One use case is when NOX is running on localhost, in which case waiting
for the full default backoff interval is unnecessary and undesirable.
Also changes default maximum backoff to 15 seconds (from 60).
Otherwise, the TCP/IP implementation is responsible for connection
attempt backoff, but we want to have some control over it ourselves.
In particular we want to initially back off faster and to log a
message upon connection attempt retransmission, to make it easier
to see what has happened from the log.
Similarly for buffer_reserve_tailroom.
The new name better reflects what they do, and make way for a different
use of the term "reserve" in the upcoming buffer_reserve() function.
It seems that this should be useful for debugging post-mortems. Also,
this ensures that the "current time is negative" log message appears in
syslog. Otherwise, it won't ever, because we log it before the vlog
client has a chance to configure its log levels.
Previously we set a few timers to expire at a time_t of 0, i.e.
immediately. But if the system date is set incorrectly to a date
before 1970, then these timers will essentially never expire.
Set them to expire at TIME_MIN instead.
Ben Pfaff