From owner-freebsd-atm Wed Nov 12 17:36:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA00506 for atm-outgoing; Wed, 12 Nov 1997 17:36:54 -0800 (PST) (envelope-from owner-freebsd-atm) Received: from eden.dei.uc.pt (eden.dei.uc.pt [193.136.212.3]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA00501 for ; Wed, 12 Nov 1997 17:36:50 -0800 (PST) (envelope-from aalves@dei.uc.pt) Received: from zorg.dei.uc.pt by eden.dei.uc.pt (5.65v3.2/1.1.10.5/28Jun97-0144PM) id AA25566; Thu, 13 Nov 1997 01:42:42 GMT Received: from localhost (aalves@localhost) by zorg.dei.uc.pt (8.8.5/8.8.5) with SMTP id BAA01456; Thu, 13 Nov 1997 01:36:58 GMT Date: Thu, 13 Nov 1997 01:36:58 +0000 (WET) From: Antonio Luis Alves To: Mark Tinguely Cc: freebsd-atm@FreeBSD.ORG Subject: Re: ATM driver & udp stream In-Reply-To: <199711121621.KAA29115@plains.NoDak.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-atm@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 12 Nov 1997, Mark Tinguely wrote: > With the permanent association between an MBUF and its external data buffer, > I keep a seperate free MBUF link list (stored on m_nextpkt) for MBUF that are > not being processed in the stack, nor are programmed in the card for new input. > Since these MBUFs can be quickly recycled, I did not want the MBUF routines > to break the MBUF to external data association only to re-establish it. This > feature also gives me an easy external data to MBUF map function. > I have seen your code when you released it, and when my problem showed I thought you probably were not experiencing the same type of problem because the way you handled the M_PERM mbufs. I liked the way you did it, because of the less overhead and the mbuf control it gives. However there was a design decision here at our group since the beginning, and it was to make the port without touching the kernel, to keep our port as much as possible close to the original. Antonio Alves