Date: Sun, 6 Sep 1998 12:10:23 +0000 From: Niall Smart <rotel@indigo.ie> To: Bill Paul <wpaul@skynet.ctr.columbia.edu>, hackers@FreeBSD.ORG Subject: Re: Questions for networking gurus Message-ID: <199809061110.MAA00667@indigo.ie> In-Reply-To: <199809042326.TAA13218@skynet.ctr.columbia.edu>; Bill Paul <wpaul@skynet.ctr.columbia.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> - The chip receives a packet and copies it into the RX buffer region. > - The driver allocates a single mbuf and sets the M_EXT flag in its > header. > - The driver determines the start address of the packet within the buffer > region and puts that address into the external data pointer of the > mbuf. > - The driver sets the mbuf's data length to the length of the packet and > specifies a free() routine to use to deallocate the external storage > when the mbuf is released. (We don't want to actually free the > buffer space though, so the free routine can be a no-op.) > - Lastly, the driver passes the mbuf to ether_input() for processing. > > This avoids a buffer copy by using an mbuf to 'encapsulate' the packet > data as an external data region, but it creates a problem: once the driver > ties a portion of the receive buffer to an mbuf, it can't allow that > portion of the buffer to be overwritten by the chip's DMA engine until > the mbuf has been released. Otherwise, the packet data will be corrupted > while another part of the kernel is fiddling with it. > > It may be possible to get around this by pre-allocating several receive > buffer areas: if all of the space in the first region has been tied to > mbufs and remains unreleased, the driver can reload the chip's receive > buffer address register with ther address of another buffer. Assuming > that all of the space in the first region will be released eventually, it > should be possible to provide room for the chip to DMA new frames while > allowing the protocols time to process existing frames in previous buffers. Hmm, is it possible to move the buffer of an M_EXT mbuf after it has been allocated, or is this asking for (race condition) trouble? If you could do this then perhaps you could perform a form of compaction whereby when there is no wholly free 32K buffer then you could move around the remaining mbufs to get an less fragmented set of buffers. I doubt this is possible though. Another alternative is to store the location of the largest contiguous free space in a buffer, so that even if you couldn't use the whole 32K you could use perhaps the lower half. This might result in more and more fragmentation over time, so perhaps every N passes over a buffer you might say "don't use this buffer until all mbufs in it are free". Of course you could also combine these approaches with copying if this would simplify things. Sounds like a silly piece of hardware to me, why isn't there an option to make it use n-byte aligned writes to the buffers? Regards, Niall -- Niall Smart, rotel@indigo.ie. Amaze your friends and annoy your enemies: echo '#define if(x) if (!(x))' >> /usr/include/stdio.h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809061110.MAA00667>