cvs commit: src/sys/netinet tcp_var.h

Andre Oppermann andre at
Sun Jun 18 13:19:06 UTC 2006

Bjoern A. Zeeb wrote:
> On Sun, 18 Jun 2006, Sam Leffler wrote:
>> Andre Oppermann wrote:
>>> andre       2006-06-17 17:57:36 UTC
>>>   FreeBSD src repository
>>>   Modified files:
>>>     sys/netinet          tcp_var.h
>>>   Log:
>>>   Rearrange fields in struct syncache and syncache_head to make them 
>>> more
>>>   cache line friendly.
>> Got any benchmarks to back this up?  Or perhaps it was just the smiley
>> face your cache lines gave you :)

The entry chains are traversed quite often and the first thing looked
at is in_conninfo and then sc_rxttime and sc_rxmits.  So it makes a
lot of sense to have them close together on the same cache line aligned
to the beginning of the struct and to the native alignment of the
architecture.  I did not benchmark it but it is simple reasoning.

> That indeed is a good question. From looking at the patch I can see
> a new lock introduced while there are other people working on reducing
> locking and locking overhead in our network stack trying different
> strategies.
> 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.


More information about the cvs-src mailing list