Date: Mon, 1 Jul 2002 08:36:29 -0500 (CDT) From: mark tinguely <tinguely@web.cs.ndsu.nodak.edu> To: rizzo@icir.org Cc: net@FreeBSD.ORG Subject: Re: Should we keep a cache of mbuf+cluster ready for use ? Message-ID: <200207011336.g61DaTW63890@web.cs.ndsu.nodak.edu> In-Reply-To: <3D203E3B.F8F91B9B@pipeline.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo wrote: > during some experiments i was doing recently, i noticed that there > is a significant improvement in the forwarding speed (especially > at very high speeds) if we keep a small pool of mbuf+cluster > ready for use. I did this a few years back with an IDT NICsTAR ATM driver. I had a privately allocated/managed chunk of memory that held MBUFs and external cluster data. I made it contiguous which is over-kill. The idea was the IDT device needed to load the external buffers into the recieve port. I did not want to waste the time allocating a MBUF, freeing the MBUF only to allocate again. I can pre-index packet header and the DMA address to take care of any expected headers. If the MBUF was allocated when the the buffer was placed into the DMA recieve queue, when the PDU was complete, we could immediately shove the MBUF/cluster into the network stack. when the network stack released the packet, a new flag on the MBUF, which I called M_PERM, signaled the free code to not break the MBUF/cluster association. Then MBUF/cluster combination was programmed into the ATM recieve buffer. (the cluster was the physical address for DMA, the MBUF was the virtual return address returned by the interrupt complete code). --mark tinguely To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200207011336.g61DaTW63890>