From owner-freebsd-net Sat Sep 9 20:13:29 2000 Delivered-To: freebsd-net@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id DDE3E37B43E for ; Sat, 9 Sep 2000 20:13:25 -0700 (PDT) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.0/8.11.0) with ESMTP id e8A3DLG62901; Sat, 9 Sep 2000 23:13:21 -0400 (EDT) (envelope-from louie@whizzo.transsys.com) Message-Id: <200009100313.e8A3DLG62901@whizzo.transsys.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Alfred Perlstein Cc: Julian Elischer , net@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: threading tcp/ip is fun. References: <20000908154320.J12231@fw.wintelcom.net> <39B9CC11.41C67EA6@elischer.org> <20000909001833.M12231@fw.wintelcom.net> In-reply-to: Your message of "Sat, 09 Sep 2000 00:18:34 PDT." <20000909001833.M12231@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 09 Sep 2000 23:13:21 -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > e.g. > > > > if (XXX) > > a_incl(a); > > if (YYY) > > a_incl(b); > > if (ZZZ) > > a_incl(c); > > > > might be slower than: > > small_lock() > > if (XXX)a+=1; > > if (YYY)b+=1; > > if (ZZZ)c+=1; > > drop_small_lock(); > > > > (in this case not likely, but it's something to keep in mind I guess.) > > Actually it's very good idea, however, right now I'm just trying > to get it SMP safe, at a later date we may want to keep CPU private > counters and in one operation update the tcpstat struct on exit > from the routine. Many moons ago, Van Jacobson did some optimizations to the TCP protocol implementation such that the code path for the "normal" TCP segement (e.g., connection already open, segment that arrives is at the left window edge, etc.) was very, very short. It would seem that locking the TCP per-connection state as a whole is probably sufficient given the short duration that the lock is likely to be held for. I don't think it makes sense to lock the individual operations since the goal is to keep the whole data structure consistant, and not just worrying about any single element. I don't see how you can convince yourself that the Right Thing happens unless you arbitrate access to the connection state as a whole. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message