cvs commit: src/sys/netinet tcp_syncache.c

[Andre Oppermann]

Robert Watson wrote:
> 
> 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.

kern.debug should not be automatically written and fsync()ed to disk.
All these TCP messages are sourced as kern.debug (except for the log_
in_vain variety with kern.info but that's something the user has to
explicitly enable).

-- 
Andre