From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 1 19:51:21 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 D316516A41F for ; Tue, 1 Nov 2005 19:51:21 +0000 (GMT) (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 2528E43D45 for ; Tue, 1 Nov 2005 19:51:16 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id jA1Jp25m020012; Tue, 1 Nov 2005 12:51:02 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4367C726.8070405@samsco.org> Date: Tue, 01 Nov 2005 12:51:02 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dinesh Nair References: <4360B8EE.4070605@alphaque.com> <4360DD7B.20900@samsco.org> <4361044B.50807@alphaque.com> <20051027.205250.55834228.imp@bsdimp.com> <4361E3E0.4090409@alphaque.com> <43676121.4030801@alphaque.com> <436791ED.8010808@samsco.org> <4367AA8D.3060506@alphaque.com> <4367BBDB.7020005@elischer.org> <4367C07C.1040900@alphaque.com> In-Reply-To: <4367C07C.1040900@alphaque.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-hackers@freebsd.org, Julian Elischer Subject: Re: locking in a device driver X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2005 19:51:21 -0000 Dinesh Nair wrote: > > > On 11/02/05 03:02 Julian Elischer said the following: > >> drops to splzero or similar,.. >> woken process called, >> starts manipulating "another buffer" >> collides with next interrupt. > > > that makes a lot of sense, i'll try with using splxxx() in the pseudo > driver, to block out the real driver. it's currently splhigh() due to > INTR_TYPE_MISC being used, but i guess i could change this to > INTR_TYPE_NET or INTR_TYPE_TTY. what would be good for a > telecommunications line card which is time sensitive and interrupts at a > constant 1000Hz ? INTR_TYPE_TTY and spltty > >> it needs to call splxxx() while it is doing it.. >> I would suggest having two buffers and swapping them under splxxx() so >> that >> the one that the driver is accessing is not the one you are draining. >> that way teh splxxx() levle needs to only be held for the small time >> you are doing the swap. > > > > the first buffer is actually the buffer into which DMA reads/writes are > done. what i referred to as "another buffer" is in fact a ring of > buffers. the real driver writes into the top of the ring, and increments > the top ring pointer. the pseudo driver reads from the bottom of the > ring and increments the bottom ring pointer. > > buf1 buf2 buf3 buf4 buf5 buf6 buf7 buf8 > ^ ^ > | | > | +-- top ring pointer, incremented as real driver reads > | from device > +-- bottom ring pointer, incremented as userland reads from pseudo > You'll also want to use an spl in the top half of the pseudo driver to cover where the pointers are read and changed. > >> not locks, but spl, >> and only step 8 needs to be changed because all teh rest are already >> done at high spl. > > > wouldnt a lockmgr() around the access to these ring buffers help since > we're locking access to data and not necessarily execution ? > lockmgr is far to heavy-weight and complex for this. Scott