Date: Thu, 27 Mar 2003 16:18:28 -0600 (CST) From: Mike Silbersack <silby@silby.com> To: Sam Leffler <sam@errno.com> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/conf options src/sys/netinet ip_output.c Message-ID: <20030327161237.T748@odysseus.silby.com> In-Reply-To: <031301c2f49b$09d2bfb0$52557f42@errno.com> References: <200303260452.h2Q4quap015364@www.ambrisko.com> <20030326183351.GJ57674@elvis.mu.org> <20030327013224.P7674@odysseus.silby.com> <031301c2f49b$09d2bfb0$52557f42@errno.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 27 Mar 2003, Sam Leffler wrote: > I thought about this some more. If the purpose of m_defrag* is to handle > problems in drivers where the s/g requirements are too large then you want > to do the minimum amount of work since the results going to be used once and > thrown away. This says to me that you want to coalesce only until you know The purpose of it is to defragment mbuf chains. As you point out, we already have m_copypacket, m_clone, and a bunch of handwritten functions in network drivers which try to do various parts of this operation, with optimizations. And, due to these optimizations, they all have shortcomings. m_defrag shouldn't be called all that often by network drivers, so I'm not overly concerned about speed issues; I'm more concerned that it achieve its goal in the most correct fashion. > and leave clusters/ext's alone. Then if the subsequent bus_dma_load_mbuf > call fails you discard the packet. Other than the read/write requirements > this is exactly m_clone. Discarding a packet because we're too lazy to defrag it isn't a very good solution. Also note that this function will be useful in other places where we are keeping mbuf chains around for long periods of time (IP reassembly) and wish to save memory at the cost of a bit of processor time. If I optimize it so that it doesn't merge mbuf clusters, it'll be a useless function. I'm sure that enhancing the function so that it stops once it reaches "goal" would be advantageous, but that's an optimization I'll let someone else do in the future. Mike "Silby" Silbersack
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030327161237.T748>