From owner-freebsd-arch@FreeBSD.ORG Sun Sep 30 18:09:42 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1FAF16A41B for ; Sun, 30 Sep 2007 18:09:42 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 2AD8213C45B for ; Sun, 30 Sep 2007 18:09:41 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona 1.7.0 Received: from [212.86.226.226] (account mav@alkar.net HELO [192.168.3.2]) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 34508769 for freebsd-arch@freebsd.org; Sun, 30 Sep 2007 20:09:40 +0300 Message-ID: <46FFD850.1040508@FreeBSD.org> Date: Sun, 30 Sep 2007 20:09:36 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Kernel thread stack usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2007 18:09:42 -0000 Hi. As known in netgraph susbystem information passing from one node to another by direct function calls without queueing. It gives performance bonuses, but it also gives permanent stack overflow risk on complicated graphs. Netgraph is still have a queues and able to use them when asked, but now queueing is a flag which should be controlled by sending node. I think it would be good to implement some algorithm which could monitor stack usage on each call and enforce queueing when stack usage become critical. The question is: is there correct way to somehow get current kernel thread stack usage or just a stack base address? -- Alexander Motin From owner-freebsd-arch@FreeBSD.ORG Sun Sep 30 18:32:30 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 037C116A419 for ; Sun, 30 Sep 2007 18:32:30 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id 88E5813C468 for ; Sun, 30 Sep 2007 18:32:29 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so2474499nfb for ; Sun, 30 Sep 2007 11:32:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=kWDYWYdzApQmLWYOZBozeve+RvdVbn8fsJrGMw7z6KY=; b=DPEUZAN6RjgcvnbjWAkst0j95OOfw5OBhnZ0AAgoRkyboWZVfTN3LXOQhCigsjoplOZM/3ekfy2Ta/XSzlepEuW1k8A4b/bIWUM9aGvL+2bFkuUQ0su7b2EDkLn/hqk9fDNwwGZ8InqVgtX4Ety1/5wjTT6vzZynSTtRtvagk3I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=efK2FApuVBtNdqagKiuojx5cg7wXsLUCpw9Jr2DnzV7C+fxX57gt1mlxsfZfcCVppSE9fCAV7+kZNBY8y4waeUBE/NB5amULC7KmVTvzyoDXwvpLb+noY9WQAY0Hzyy2JseQMZsua1+ZTWCT+cp3R9WKzF98ZemqKyVNB/FH/7U= Received: by 10.78.159.7 with SMTP id h7mr2153750hue.1191177147610; Sun, 30 Sep 2007 11:32:27 -0700 (PDT) Received: by 10.78.97.18 with HTTP; Sun, 30 Sep 2007 11:32:27 -0700 (PDT) Message-ID: <3bbf2fe10709301132j441277e1web97323743d01560@mail.gmail.com> Date: Sun, 30 Sep 2007 20:32:27 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Alexander Motin" In-Reply-To: <46FFD850.1040508@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46FFD850.1040508@FreeBSD.org> X-Google-Sender-Auth: da1a032cc9ac9d3f Cc: freebsd-arch@freebsd.org Subject: Re: Kernel thread stack usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2007 18:32:30 -0000 2007/9/30, Alexander Motin : > Hi. > > As known in netgraph susbystem information passing from one node to > another by direct function calls without queueing. It gives performance > bonuses, but it also gives permanent stack overflow risk on complicated > graphs. Netgraph is still have a queues and able to use them when asked, > but now queueing is a flag which should be controlled by sending node. I > think it would be good to implement some algorithm which could monitor > stack usage on each call and enforce queueing when stack usage become > critical. > > The question is: is there correct way to somehow get current kernel > thread stack usage or just a stack base address? This should be stored in the pcb area of threads (for example, ia32 maintains a pcb_esp0 which points to the stack address at ring0 for the thread which points to). Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Sun Sep 30 18:45:49 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEC8116A41A; Sun, 30 Sep 2007 18:45:49 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 4B6CA13C447; Sun, 30 Sep 2007 18:45:49 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 759BF1A4D80; Sun, 30 Sep 2007 11:24:27 -0700 (PDT) Date: Sun, 30 Sep 2007 11:24:27 -0700 From: Alfred Perlstein To: Alexander Motin Message-ID: <20070930182427.GY53439@elvis.mu.org> References: <46FFD850.1040508@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46FFD850.1040508@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-arch@freebsd.org Subject: Re: Kernel thread stack usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2007 18:45:49 -0000 * Alexander Motin [070930 11:09] wrote: > Hi. > > As known in netgraph susbystem information passing from one node to > another by direct function calls without queueing. It gives performance > bonuses, but it also gives permanent stack overflow risk on complicated > graphs. Netgraph is still have a queues and able to use them when asked, > but now queueing is a flag which should be controlled by sending node. I > think it would be good to implement some algorithm which could monitor > stack usage on each call and enforce queueing when stack usage become > critical. > > The question is: is there correct way to somehow get current kernel > thread stack usage or just a stack base address? Not that I know of, but one could defer to queueing once the chain gets to a certain length. -- - Alfred Perlstein From owner-freebsd-arch@FreeBSD.ORG Sun Sep 30 19:17:36 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF54D16A418; Sun, 30 Sep 2007 19:17:36 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 05F9813C480; Sun, 30 Sep 2007 19:17:35 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona 1.7.0 Received: from [212.86.226.226] (account mav@alkar.net HELO [192.168.3.2]) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 34522168; Sun, 30 Sep 2007 22:17:35 +0300 Message-ID: <46FFF64B.3030700@FreeBSD.org> Date: Sun, 30 Sep 2007 22:17:31 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alfred Perlstein References: <46FFD850.1040508@FreeBSD.org> <20070930182427.GY53439@elvis.mu.org> In-Reply-To: <20070930182427.GY53439@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-arch@freebsd.org Subject: Re: Kernel thread stack usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2007 19:17:37 -0000 Alfred Perlstein ?????: > Not that I know of, but one could defer to queueing once the chain > gets to a certain length. It will not be accurate as different nodes have different stack usage and also stack partially used (part may be significant) before packet entered netgraph. -- Alexander Motin From owner-freebsd-arch@FreeBSD.ORG Sun Sep 30 21:24:38 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A139316A41B; Sun, 30 Sep 2007 21:24:38 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5166213C4A7; Sun, 30 Sep 2007 21:24:38 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.103] (c-67-160-44-208.hsd1.wa.comcast.net [67.160.44.208]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l8ULOaOk042885 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sun, 30 Sep 2007 17:24:37 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Sun, 30 Sep 2007 14:27:15 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Alexander Motin In-Reply-To: <46FFF64B.3030700@FreeBSD.org> Message-ID: <20070930142545.V583@10.0.0.1> References: <46FFD850.1040508@FreeBSD.org> <20070930182427.GY53439@elvis.mu.org> <46FFF64B.3030700@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alfred Perlstein , freebsd-arch@freebsd.org Subject: Re: Kernel thread stack usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2007 21:24:38 -0000 On Sun, 30 Sep 2007, Alexander Motin wrote: > Alfred Perlstein ?????: >> Not that I know of, but one could defer to queueing once the chain >> gets to a certain length. > > It will not be accurate as different nodes have different stack usage and > also stack partially used (part may be significant) before packet entered > netgraph. Does it really need to be that precise? If you queue every 10 or 20 deep the queueing cost should be substantially amortized and it sounds like this is not a common condition anyway or the stack would already be overflowing with some workloads. Jeff > > -- > Alexander Motin > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Mon Oct 1 04:35:09 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98A7916A419 for ; Mon, 1 Oct 2007 04:35:09 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outQ.internet-mail-service.net (outQ.internet-mail-service.net [216.240.47.240]) by mx1.freebsd.org (Postfix) with ESMTP id 7D0FD13C43E for ; Mon, 1 Oct 2007 04:35:09 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Sun, 30 Sep 2007 21:22:07 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id BA712126547; Sun, 30 Sep 2007 21:22:06 -0700 (PDT) Message-ID: <470075EE.1030104@elischer.org> Date: Sun, 30 Sep 2007 21:22:06 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Alexander Motin References: <46FFD850.1040508@FreeBSD.org> In-Reply-To: <46FFD850.1040508@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Kernel thread stack usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2007 04:35:09 -0000 Alexander Motin wrote: > Hi. > > As known in netgraph susbystem information passing from one node to > another by direct function calls without queueing. It gives performance > bonuses, but it also gives permanent stack overflow risk on complicated > graphs. Netgraph is still have a queues and able to use them when asked, > but now queueing is a flag which should be controlled by sending node. I > think it would be good to implement some algorithm which could monitor > stack usage on each call and enforce queueing when stack usage become > critical. > > The question is: is there correct way to somehow get current kernel > thread stack usage or just a stack base address? > I've thought about this quite a bit over the years. On possibility is a stack usage meter (which once did work out) and another is to have a 'hop count (or recursion count) added to the arguments passed around with the data. The nodes would have to cooperate with this scheme. The counter could be in the 'item' or an explicit argument. The 'recursion depth' counter may or may not be the same thing as a 'hop count' that could be kept in the mbuf. it is possible both make sense two mbuf counters. one oncremented whenever there is am mbuf handoff that doesn't involve queueing, and is cleared to 0 whenever queueing is invoked, and one that is continually incremented until the packet leaves the machine.. one to stop packets permanently circulating around a machine and one for stack protection.. From owner-freebsd-arch@FreeBSD.ORG Mon Oct 1 08:57:31 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E68C916A417 for ; Mon, 1 Oct 2007 08:57:31 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 6404513C48A for ; Mon, 1 Oct 2007 08:57:31 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona 1.7.0 Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 34624293; Mon, 01 Oct 2007 11:57:30 +0300 Message-ID: <4700B679.3070909@FreeBSD.org> Date: Mon, 01 Oct 2007 11:57:29 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.0 (X11/20070424) MIME-Version: 1.0 To: Julian Elischer References: <46FFD850.1040508@FreeBSD.org> <470075EE.1030104@elischer.org> In-Reply-To: <470075EE.1030104@elischer.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Kernel thread stack usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2007 08:57:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Julian Elischer wrote: > two mbuf counters. one oncremented whenever there is am mbuf handoff > that doesn't involve queueing, and is cleared to 0 whenever queueing is > invoked, > and one that is continually incremented until the packet leaves the > machine.. > > one to stop packets permanently circulating around a machine and one for > stack protection.. Using counter in item will not help in case where packet leaves netgraph, but will come back later. Also item can be destroyed and recreated by some nodes like ng_ppp. And even except this counter will not be a best solution as for example ng_tee node have significantly lower stack usage then previous version of ng_bpf or tcp stack call from ksocket. ng_tee node can handle a hundres, while previous ng_bpf would die after 25 calls. - -- Alexander Motin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHALZ50kCgngV3usoRAuP2AJ9L87iQss1an2qGEbp9jKYZXW4wdwCdExYp 66aJPV7WqTE1S/Fao1L6Ik4= =7Enh -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Tue Oct 2 19:02:23 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CF7D16A4CC for ; Tue, 2 Oct 2007 19:02:23 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 1E13213C455 for ; Tue, 2 Oct 2007 19:02:20 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [85.19.218.45] (account mc467741@c2i.net [85.19.218.45] verified) by mailfe01.swip.net (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 615070863; Tue, 02 Oct 2007 21:02:18 +0200 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Tue, 2 Oct 2007 21:02:37 +0200 User-Agent: KMail/1.9.7 References: <200709260131.49156.hselasky@c2i.net> <200709262157.02712.hselasky@c2i.net> <46FB03B1.6020100@samsco.org> In-Reply-To: <46FB03B1.6020100@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710022102.38495.hselasky@c2i.net> Cc: Scott Long Subject: Re: Request for feedback on common data backstore in the kernel X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2007 19:02:23 -0000 On Thursday 27 September 2007, Scott Long wrote: > Hans Petter Selasky wrote: > > > > I'm thinking about putting some wrappers around the "bus_dmamap_load()" > > function like: > > > > void usbd_rx_buf_load(struct usbd_xfer *xfer, void *buf, > > uint32_t framebuffer_offset, uint32_t framebuffer_index, uint32_t len); > > > > void usbd_tx_buf_load(struct usbd_xfer *xfer, void *buf, > > uint32_t framebuffer_offset, uint32_t framebuffer_index, uint32_t len); > > > > But I haven't figured out all the details yet. The "usbd_xxx_load()" > > functions should automagically figure out what is best to do and it won't > > be more than a few lines of code. > > Can you describe what these two wrappers are supposed to do? Basically these wrappers will setup the DMA address for the USB HC driver. If they need to copy data they will copy data. > Are you expecting bus_dmamap_load() to operate synchronously? Yes. I assume that "bus_dmamap_load()" can sleep and consequently needs a thread context. --HPS From owner-freebsd-arch@FreeBSD.ORG Tue Oct 2 23:40:07 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 517C516A417 for ; Tue, 2 Oct 2007 23:40:07 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 0DBEF13C4A6 for ; Tue, 2 Oct 2007 23:40:06 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l92NdkdQ006496; Tue, 2 Oct 2007 17:39:47 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4702D6B9.1080206@samsco.org> Date: Tue, 02 Oct 2007 17:39:37 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Hans Petter Selasky References: <200709260131.49156.hselasky@c2i.net> <200709262157.02712.hselasky@c2i.net> <46FB03B1.6020100@samsco.org> <200710022102.38495.hselasky@c2i.net> In-Reply-To: <200710022102.38495.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Tue, 02 Oct 2007 17:39:47 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-arch@freebsd.org Subject: Re: Request for feedback on common data backstore in the kernel X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2007 23:40:07 -0000 Hans Petter Selasky wrote: > On Thursday 27 September 2007, Scott Long wrote: >> Hans Petter Selasky wrote: > >>> I'm thinking about putting some wrappers around the "bus_dmamap_load()" >>> function like: >>> >>> void usbd_rx_buf_load(struct usbd_xfer *xfer, void *buf, >>> uint32_t framebuffer_offset, uint32_t framebuffer_index, uint32_t len); >>> >>> void usbd_tx_buf_load(struct usbd_xfer *xfer, void *buf, >>> uint32_t framebuffer_offset, uint32_t framebuffer_index, uint32_t len); >>> >>> But I haven't figured out all the details yet. The "usbd_xxx_load()" >>> functions should automagically figure out what is best to do and it won't >>> be more than a few lines of code. >> Can you describe what these two wrappers are supposed to do? > > Basically these wrappers will setup the DMA address for the USB HC driver. If > they need to copy data they will copy data. Bouncing/copying is built into the busdma API. If there's a reason to duplicate that logic in USB, please let me know. > >> Are you expecting bus_dmamap_load() to operate synchronously? > > Yes. I assume that "bus_dmamap_load()" can sleep and consequently needs a > thread context. Actually, it's the opposite. The API is meant to NOT block, it is meant to run in whatever context you want, and it'll provide it's own context for delayed loads to run in. This is very different than NetBSD, so if you haven't read the man page yet, I'd recommend doing so. Scott