From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 22 12:57:01 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 5FD4237B404; Tue, 22 Jul 2003 12:57:01 -0700 (PDT) Received: from garple.migus.org (pcp243383pcs.howard01.md.comcast.net [68.55.83.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 292AF43FA3; Tue, 22 Jul 2003 12:57:00 -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 h6MJuw6a024881; Tue, 22 Jul 2003 15:56:58 -0400 (EDT) (envelope-from adam@migus.org) Received: (from www@localhost) by garple.migus.org (8.12.9/8.12.9/Submit) id h6MJuw4m024880; Tue, 22 Jul 2003 15:56:58 -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 15:56:58 -0400 (EDT) Message-ID: <34134.204.254.155.100.1058903818.squirrel@mail.migus.org> In-Reply-To: References: <63051.204.254.155.100.1058895811.squirrel@mail.migus.org> Date: Tue, 22 Jul 2003 15:56:58 -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=-0.9 required=5.0 tests=IN_REP_TO,PRIORITY_NO_NAME,REFERENCES,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 19:57:01 -0000 Robert Watson said: > > Well, the case I had particularly in mind was the rapid > flow of packets > form the kernel to the user process; Pawel's suggestion > handles the flow > of new data from the user process to the kernel well, > and has substantial > similarity to some of the IO Lite mechanisms I pointed > at (and hopefully > with many of the same performance benefits). In the > kernel-to-userspace > case, we want to avoid the copy of what is originally > kernel-owned memory > (from the mbuf allocator) to the user process memory. > If you didn't care > about stuff like confidentiality of kernel memory, etc, > the simplest > approach would be to actually map the mbuf memory (and > possibly cluster) > into userspace, and then notify the user process in > some form of the new > mapping. However, because mbufs and their meta-data > aren't page aligned > (etc, etc, etc), you really don't want to do it > explicitly that way, I > suspect. Ok, I think I understand a little better. The DMA analogy combined with the somewhat obscure bracketed requirements below it caused me to get a little confused. As for the page alignment issue have you checked out the new MBUMA stuff Bosko's doing? It uses (and abstracts) mbuf allocation over uma. Perhaps it could be taylored to fit your requirements. > > By synchronization, I had in mind a mechanism by which > the process and > kernel would communicate about memory ownership in the > shared memory > space: "I'm done with this packet", "I'm done with > these packets", "I want > to continue delivery of that packet", "I modified this > packet", "I'm > inserting a new packet here", "I'm dropping this > packet", all without > extensive memory copying, and with a moderate amount of > asynchrony (and > possibly parallelism). In terms of functionality, it > might be similar to > some of the current services that forward between > IPDIVERT "in" and "out" > (such as natd), or between BPF pseudo-devices. This > sounds like something > that likely exists in a few commercial products > already, so my question to > Terry was to whether he knew of any in the literature. > IOLite is the > closest I know of, as it supports the zero-copy page > and memory ownership > bits, although I don't know if they allowed it to > handle packets, perhaps > just datagrams and streams. > Given my comments above would it not be possible to offer this mechanism as an extension to the mbuf's own meta-data? -- Adam Migus - Research Scientist Network Associates Laboratories (http://www.nailabs.com)