cvs commit: src/sys/netinet tcp_var.h

[Robert Watson]

On Sun, 18 Jun 2006, Andre Oppermann wrote:

>> I hadn't seen a patch or any numbers in this months arch@ or net@ archives 
>> (maybe I missed it?). At the current phase of network stack hacking we 
>> should take the time to get these kind of changes benchmarked under various 
>> loads from different people or at least give them the chance to do so so 
>> nobody can complain afterwards. At least if one wants to claim performance 
>> improvements.
>
> Robert Watson and Paul Saab ran the syncache locking changes in their 
> testbeds and found 0.7% and 0% regression.  The syncache locking will have 
> its benefits when we deserialize the packet input path.  Also the global 
> tcpinfo lock is held for only a very short amount of time instead of the 
> whole time.

While the technical argument for the patch is good, I think the general tone 
of caution expressed by Sam, Bjoern, et al, is also important: over the past 
ten years, a lot of changes have been made that are considered "long term 
architectural investments" -- that is, changes that pessimize in the short 
term and are intended to optimize in the long term.  The caution is 
appropriate because in many cases, the long term optimizations have yet to 
materialize, leaving us with lots of short term pessimizations.  For massive 
architectural changes, such as fundamental changes in synchronization model, 
this is sometimes necessary, but for smaller point changes, maintaining and 
testing out of the tree is both feasible and often desirablej

There's a lot to be said for keeping significant works in progress in working 
branches in Perforce until it can be demonstrated that the eventual wins can 
in fact be realized by the proposed approach.  Keeping the WIP's in Perforce 
doesn't necessarily mean reduced review and exposure -- it makes it easier to 
point test specific changes in test environments, and plug-and-play changes in 
test combinations without committing to the changes by merging them to CVS, 
which is valuable.  I know that Kris and I (and no doubt others) find Perforce 
a valuable tool for sharing working branches, since versioned patchsets are no 
longer required, which makes testing and review much harder.  Working in 
Perforce also gives more access to incremental review -- something our SoC 
students are learning rapidly, as they start getting feedback on their works 
in progress from people they've never heard of! :-)

Robert N M Watson
Computer Laboratory
University of Cambridge