cvs commit: src/sys/netinet tcp_syncache.c

[Robert Watson]

On Thu, 24 May 2007, Gleb Smirnoff wrote:

> A>  W/o logging we have no way of really knowing.  Before we were possibly
> A>  accepting stuff we shouldn't have (spoofing and attacks).  Now we may
> A>  drop stuff we perhaps should accept anyway.  W/o logging diagnosing a
> A>  TCP problem was very difficult and would need a lot cooperation with
> A>  the PR submitter, if it was submitted at all.  We normally only got a
> A>  report of TCP 'not working'.  Figuring out what went wrong was pretty
> A>  much doing iterative shots into the dark and see if something squeaks.
> A>
> A>  With logging I want to make things much more obvious and simpler to
> A>  diagnose.  Plus we get information in cases (from admins reading the
> A>  logs) that were totally lost in the noise or not even attempted to
> A>  be debugged.
> A>
> A>  For our TCP maintainers (mostly I at the moment) and also 3rd parties
> A>  this makes TCP trouble diagnosis much more accessible.  Based on a
> A>  log report and the OS name/version of the remote end we can pretty
> A>  much tell right away what went wrong.  This saves an order of a
> A>  magnitude in debugging and fault analysis time.  From many hours and
> A>  email round trips to mere minutes and one or two information requests.
>
> I completely understand that this logging is very important in the process 
> of refactoring the TCP code. I just think that the performance impact should 
> be measured before merging this logging to RELENG_6.

Kernel-sourced log messages result in an fsync() of log files the message is 
written to, as syslogd feels that kernel messages are very important and 
should go to disk as quickly and reliably as possible.  As a result, it's very 
desirable to rate limit (ideally no more than 1pps) packet-generated log 
messages.  I've been thinking of adding a spp function to match ppsprint for 
things like kernel warnings about the audit trail storage partition filling 
up, as one message a second is still a lot.

Robert N M Watson
Computer Laboratory
University of Cambridge