From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 22 10:43:37 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB6BC37B401; Tue, 22 Jul 2003 10:43:36 -0700 (PDT) Received: from garple.migus.org (pcp243383pcs.howard01.md.comcast.net [68.55.83.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8EF243F93; Tue, 22 Jul 2003 10:43:33 -0700 (PDT) (envelope-from adam@migus.org) Received: from garple.migus.org (localhost [127.0.0.1]) by garple.migus.org (8.12.9/8.12.9) with ESMTP id h6MHhW6a023583; Tue, 22 Jul 2003 13:43:32 -0400 (EDT) (envelope-from adam@migus.org) Received: (from www@localhost) by garple.migus.org (8.12.9/8.12.9/Submit) id h6MHhVf9023582; Tue, 22 Jul 2003 13:43:31 -0400 (EDT) X-Authentication-Warning: garple.migus.org: www set sender to adam@migus.org using -f Received: from 204.254.155.100 (SquirrelMail authenticated user adam) by mail.migus.org with HTTP; Tue, 22 Jul 2003 13:43:31 -0400 (EDT) Message-ID: <63051.204.254.155.100.1058895811.squirrel@mail.migus.org> In-Reply-To: References: <20030721190146.GB43543@garage.freebsd.pl> Date: Tue, 22 Jul 2003 13:43:31 -0400 (EDT) From: "Adam Migus" To: "Robert Watson" User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Status: No, hits=-1.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,PRIORITY_NO_NAME,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT,X_AUTH_WARNING version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-hackers@freebsd.org Subject: Re: Communications kernel -> userland X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2003 17:43:37 -0000 Robert Watson said: > > On Mon, 21 Jul 2003, Pawel Jakub Dawidek wrote: > >> For example syscall is marking some range with mark() >> function. For now >> on this range isn't accessable from userland. If >> process will try to >> write to this page, page is copied (copy-on-write). >> If this page will >> be modified by kernel it will be marked as MODIFIED. >> Now when syscall >> will call unmark() on this range we could get two >> scenarious: >> >> 1. Page is marked as MODIFIED (by kernel) so >> userland copy >> of this page (if it exists of course) is >> destroyed and >> this page will be putted in its place. >> This is replacement for copyin() and then >> copyout() or >> just copyout().. >> 2. Page isn't marked as MODIFIED, so kernel version >> of page >> is destroyed (is there is userland version). >> This is replacement for just copyin(). >> >> There could be other ways. Thread/process could be >> locked if it is >> trying to access memory marked with mark() function. >> And this, I think, >> don't hit performance, because this happends really >> rarely. So maybe it >> is better to lock thread for a moment instead of >> doplicating page, but I >> don't think so. > > This sounds a bit like some of the IO Lite stuff -- > moving to a > page-centric model for IO interfaces to avoid copy > operations, in many > cases able to share pages between applications, buffer > cache, network > buffers, etc. Take a look at: > > http://www.cs.princeton.edu/~vivek/ > > For some details. Some of the benefits of this > approach are captured in > the common case through sendfile(), in practice, but > it's definitely worth > a read. > > I guess what I had in mind was something more > network-specific, with > interfaces optimized for memory mapped network packet > streams. In the > simplest case, something like memory-mapping the BPF > buffer from kernel > space to userspace, with some sort of simple stream > synchronization so > that the user application could notify the kernel as to > when it could > reuse bits of the buffer, but avoiding copy operations > and lots of context > switching. > > Robert N M Watson FreeBSD Core Team, > TrustedBSD Projects > robert@fledge.watson.org Network Associates > Laboratories > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" > Perhaps I'm not understanding you right but I think Pawel's idea is cool. It seems to fulfill your requirements (except being network specific). I suppose if it were network specific we could optimize it for packet streams and if we made it complicated enough it would require quite an elaborate sychronization and notification mechanism. Is that closer to what have in mind? -- Adam Migus - Research Scientist Network Associates Laboratories (http://www.nailabs.com)