Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 8 Dec 2008 20:27:00 +0000 (UTC)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        cvs-src-old@freebsd.org
Subject:   cvs commit: src/sys/netinet tcp_input.c
Message-ID:  <200812082027.mB8KR7ii017343@repoman.freebsd.org>

next in thread | raw e-mail | index | archive | help
rwatson     2008-12-08 20:27:00 UTC

  FreeBSD src repository

  Modified files:
    sys/netinet          tcp_input.c 
  Log:
  SVN rev 185775 on 2008-12-08 20:27:00Z by rwatson
  
  Move from solely write-locking the global tcbinfo in tcp_input()
  to read-locking in the TCP input path, allowing greater TCP
  input parallelism where multiple ithreads or ithread and netisr
  are able to run in parallel.  Previously, most TCP input paths
  held a write lock on the global tcbinfo lock, effectively
  serializing TCP input.
  
  Before looking up the connection, acquire a write lock if a
  potentially state-changing flag is set on the TCP segment header
  (FIN, RST, SYN), and otherwise a read lock.  We may later have
  to upgrade to a write lock in certain cases (ACKs received by the
  syncache or during TIMEWAIT) in order to support global state
  transitions, but this is never required for steady-state packets.
  
  Upgrading from a write lock to a read lock must be done as a
  trylock operation to avoid deadlocks, and actually violates the
  lock order as the tcbinfo lock preceeds the inpcb lock held at
  the time of upgrade.  If the trylock fails, we bump the refcount
  on the inpcb, drop both locks, and re-acquire in-order.  If
  another thread has freed the connection while the locks are
  dropped, we free the inpcb and repeat the lookup (this should
  hardly ever or never happen in practice).
  
  For now, maintain a number of new counters measuring how many
  times various cases execute, and in particular whether various
  optimistic assumptions about when read locks can be used, whether
  upgrades are done using the fast path, and whether connections
  close in practice in the above-described race, actually occur.
  
  MFC after:      6 weeks
  Discussed with: kmacy
  Reviewed by:    bz, gnn, kmacy
  Tested by:      kmacy
  
  Revision  Changes    Path
  1.394     +276 -61   src/sys/netinet/tcp_input.c



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200812082027.mB8KR7ii017343>