From owner-freebsd-net Mon Dec 11 9:43:54 2000 From owner-freebsd-net@FreeBSD.ORG Mon Dec 11 09:43:51 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id 45A5437B402 for ; Mon, 11 Dec 2000 09:43:51 -0800 (PST) Received: from modemcable213.3-201-24.mtl.mc.videotron.ca ([24.201.3.213]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G5E00L9SZX0Q5@falla.videotron.net> for net@freebsd.org; Mon, 11 Dec 2000 12:43:48 -0500 (EST) Date: Mon, 11 Dec 2000 12:44:55 -0500 (EST) From: Bosko Milekic Subject: Re: Abusing m_ext for a worthy goal. In-reply-to: <20001211014837.W16205@fw.wintelcom.net> To: Alfred Perlstein Cc: net@freebsd.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Alfred, On Mon, 11 Dec 2000, Alfred Perlstein wrote: > Ok, part of the mp cleanup got me looking at af_unix sockets. > > Here's the deal, descriptors can be called "in-flight" meaning they > have been passed from one application to another via > CMG_DATA but not picked up on the other side yet. > > The kernel does a bunch of hokey stuff to garbage collect them. > > Instead of doing that I'd like to abuse MEXTADD to setup a callback > to remove the references automagicaly when the mbuf it free'd. > > Here's the problem: > > I want to use the mbuf clusters, I don't want to use any special > external storage. I want my callback to free the cluster. > > Any hints on how to do this? > > here's what I have so far: > > MEXTADD(control, mtod(control, char *), control->m_len, unp_mbfree, > cm, M_RDONLY, EXT_CMSG_DATA); > > control is a mbuf with a cluster attached the has fd's written in it. > cm is a pointer to the mbuf cluster. Here, the general idea is correct, but you'll have to do things this way: #define EXT_CMSG_DATA 666 /* A hack, for now. */ An allocation: /* Here make sure you're not holding any other mutex. */ mtx_enter(&mclfree.m_mtx, MTX_DEF); _MCLALLOC(control->m_ext.ext_buf, M_WAIT); /* Or M_DONTWAIT */ mtx_exit(&mclfree.m_mtx, MTX_DEF); if (control->m_ext.ext_buf != NULL) { /* Assuming you want to M_RDONLY your data. Otherwise, just change M_RDONLY to 0. */ MEXTADD(control, control->m_ext.ext_buf, MCLBYTES, unp_mbfree, cm, M_RDONLY, EXT_CMSG_DATA); if (control->m_ext.ref_cnt == NULL) { _MCLFREE(control->m_ext.ext_buf); /* Allocation of ref. counter failed, so just fail gracefully instead of panic (this should never happen, but make sure to check. */ return (ENOBUFS); } } else return (ENOBUFS); > static void > unp_mbfree(caddr_t mm, void *claddr) > { > struct mbuf *m = (struct mbuf *)mm; > > unp_scan(m, unp_discard); > _MCLFREE(claddr); > } Actually, your free routine needs to accept the address of the cluster as a first argument, and the optional argument as a second argument. According to your MEXTADD() above, your optional argument will be something called "cm." In your case, what you need to make your optional argument be is the actual mbuf "control" (you can cast it to struct mbuf *). Then, you can call unp_scan() on that mbuf (second argument) and call _MCLFREE() on the first argument, which will effectively be the address of the cluster. > does this look right? would you like to abstract the mbuf > clusters further before i started using the _ macros? Abstracting mbuf clusters is deffinately something I'm looking at doing (as you've probably seen me mention on some posts to some of the lists), but for now, the above should do. I'd rather not rush into abstracting the EXT_CLUSTER type further for now "just for the sake of abstracting it." I want to make sure that we don't lose any performance whatsoever for what concerns clusters (i.e. I'm trying to decide on whether the cost of calling a function for clusters as well is worth it at this point). Briefly, the day will come. :-) > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > "I have the heart of a child; I keep it in a jar on my desk." Cheers, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message