Date: Sat, 9 Sep 2000 00:18:34 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Julian Elischer <julian@elischer.org> Cc: net@freebsd.org Subject: Re: threading tcp/ip is fun. Message-ID: <20000909001833.M12231@fw.wintelcom.net> In-Reply-To: <39B9CC11.41C67EA6@elischer.org>; from julian@elischer.org on Fri, Sep 08, 2000 at 10:35:13PM -0700 References: <20000908154320.J12231@fw.wintelcom.net> <39B9CC11.41C67EA6@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* Julian Elischer <julian@elischer.org> [000908 22:35] wrote: > Alfred Perlstein wrote: > > > > http://www.wintelcom.net/~bright/thrsock.diff > > > > Should refresh every two minutes as I progress through the tcp/ip > > code in an attempt to thread it. > > > > If you have suggestions or works in progress please let me know. > > > There is a lot of use of "atomic_ad_long()" > nearly always with an increment of '1'. > Would there be any advantage of having an > "atomic_increment_long()"? > (a_incl()) > > with the introduction of heavier weight operations at low level > (e.g."atomic_add_long(a , 1);" vs "a += 1;" > the optimal way if unrolling loops and threading decision > trees may change.. > > 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. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000909001833.M12231>