Date: Tue, 18 Feb 2003 02:19:13 +0100 From: Maxime Henrion <mux@freebsd.org> To: "Justin T. Gibbs" <gibbs@scsiguy.com> Cc: Sam Leffler <sam@freebsd.org>, Perforce Change Reviews <perforce@freebsd.org> Subject: Re: PERFORCE change 24844 for review Message-ID: <20030218011913.GF60813@elvis.mu.org> In-Reply-To: <47870000.1045456722@aslan.scsiguy.com> References: <200302082030.h18KUuR9063864@repoman.freebsd.org> <47870000.1045456722@aslan.scsiguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Justin T. Gibbs wrote: > > http://perforce.freebsd.org/chv.cgi?CH=24844 > > > > Change 24844 by sam@sam_ebb on 2003/02/08 12:30:08 > > > > bus_dma'd em driver (works on x86, not on sparc) > > replace rx logic with jumbo buffers (needs more work) > There are lots of things that are a bit wierd about how this > was bus dma'ed... [...] > o bus dmamaps have a lifetime of a single packet. While loading a map > is usually cheap, allocating a map may be very costly. The implementation > may use the allocation of a map as a hint to increase its mapping space, > bounce buffer pool, or to perform some other action that will decrease > the chance that a load will block should all maps currently allocated > against the tag be used at once. The map may be a fairly large object > depending on the needs of the implementation. I would suggest changing > the maps to have the same lifetime as the TX descriptors. [...] Are you just talking about TX descriptors, or also RX ones? Having dma maps with the same lifetime as the descriptor is easy for the TX case, but it's actually quite hard for the RX case. FWIW, When I converted the xl(4) driver to busdma, I made it so RX dma maps have the same lifetime as the RX descriptor, and was only doing bus_dmamap_load() when mapping another packet, but I will probably soon change this and create a new dma map for each packet. The reason for this is the way we handle memory shortage in the drivers. When xl_newbuf() fails, we don't pass the packet to the upper layer and instead reuse the mbuf to get another packet. That's OK in the non-busdma case, but in the busdma case, we need to handle another possible failure with the bus_dmamap_load() call. The problem is that we already did call bus_dmamap_unload() and the "old" mbuf isn't mapped anymore. And since we can't do selective bus_dmamap_unload() calls, we can't just unmap it after we succeded in mapping the new mbuf. It would probably be better to fix the busdma API so that we can selectively unload one mapping from a map, but until we got this feature I'll move the map creation at mbuf allocation time. Fixing this problem differently without touching the busdma code implies having an RX descriptors list for those descriptors we failed to map, so that we can try to use them again later. This has far-reaching consequences, as we'll have to modify the RX descriptor chain, and many drivers statically chain the descriptors for performance reasons... IMHO that's way too much complexity. Of course, I would be happy to be told that I missed some point and there's an even better way of fixing this than what I'm currently planning on committing :-). Cheers, Maxime To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe p4-projects" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030218011913.GF60813>