From owner-freebsd-net Sat Jul 15 10:48:27 2000 Delivered-To: freebsd-net@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id BCA5037BC9F; Sat, 15 Jul 2000 10:48:23 -0700 (PDT) (envelope-from bmilekic@dsuper.net) Received: from modemcable009.62-201-24.mtl.mc.videotron.net ([24.201.62.9]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0FXR007K52OUJD@falla.videotron.net>; Sat, 15 Jul 2000 13:46:06 -0400 (EDT) Date: Sat, 15 Jul 2000 13:48:29 -0400 (EDT) From: Bosko Milekic Subject: Re: mbuf refcnt and sendfile In-reply-to: X-Sender: bmilekic@jehovah.technokratis.com To: Alfred Perlstein Cc: net@FreeBSD.ORG, dg@FreeBSD.ORG, dillon@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > When you increase the reference count, it's not exactly atomic as > you may be offsetting into a location, it may produce more than one > instruction in which case you may catch an interrupt in between where > things will get broken. I just thought of something that would essentially change this and make your assumption correct for the issue of atomicity. However, I still think that it's better to not maintain an external reference counter for each ext_buf mainly for the reason of transparency. But I guess what you could do, if you really insist on it is, in m_ext: union { u_int counter; u_int *countr; } count; The first referrer can use the u_int counter and the rest can point their *countr's to this first mbuf's counter. This would avoid the external management of a reference counter. It might indeed make these operations more optimized. I made the changes already so I'll post them a little later today, if you want. Personally, though, I preferred to have all of the mbufs referring to the same external object easily accessible through any of the isolated mbufs. --Bosko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message