From owner-cvs-src@FreeBSD.ORG Thu Mar 27 14:21:56 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C9C237B401 for ; Thu, 27 Mar 2003 14:21:56 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 2885643F93 for ; Thu, 27 Mar 2003 14:21:54 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 31581 invoked from network); 27 Mar 2003 22:21:53 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 27 Mar 2003 22:21:53 -0000 X-pair-Authenticated: 209.68.2.70 Date: Thu, 27 Mar 2003 16:18:28 -0600 (CST) From: Mike Silbersack To: Sam Leffler In-Reply-To: <031301c2f49b$09d2bfb0$52557f42@errno.com> Message-ID: <20030327161237.T748@odysseus.silby.com> References: <200303260452.h2Q4quap015364@www.ambrisko.com> <20030326183351.GJ57674@elvis.mu.org> <20030327013224.P7674@odysseus.silby.com> <031301c2f49b$09d2bfb0$52557f42@errno.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-23.8 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: Maxime Henrion cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: Doug Ambrisko cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/conf options src/sys/netinet ip_output.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2003 22:21:58 -0000 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