From owner-svn-src-all@FreeBSD.ORG Wed Nov 20 20:21:58 2013 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E048F591; Wed, 20 Nov 2013 20:21:58 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id BC7F526DD; Wed, 20 Nov 2013 20:21:58 +0000 (UTC) Received: from c0188.aw.cl.cam.ac.uk (c0188.aw.cl.cam.ac.uk [128.232.100.188]) by cyrus.watson.org (Postfix) with ESMTPSA id 753F746B2C; Wed, 20 Nov 2013 15:21:50 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: svn commit: r258328 - head/sys/net From: "Robert N. M. Watson" In-Reply-To: <528D1768.9000401@freebsd.org> Date: Wed, 20 Nov 2013 20:21:47 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201311182258.rAIMwEFd048783@svn.freebsd.org> <528D1768.9000401@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1822) Cc: svn-src-head@freebsd.org, George Neville-Neil , svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 20:21:59 -0000 On 20 Nov 2013, at 20:11, Julian Elischer wrote: >> Currently, it is quite easy to make mistakes regarding individual = mbuf chains vs. lists of mbuf chains. This leads me to wonder whether a = new type, perhaps simply constructed on the stack before passing in, = should be used for KPIs that accept lists of packets. E.g., >>=20 >> /* >> * This structure is almost always allocated on a caller stack, so >> * cannot itself be queued without memory allocation in most = cases. >> */ >> struct mbuf_queue { >> struct mbuf *mq_head; >> }; >>=20 >>=20 > It's hard to believe that we don't have a structure around already = that we can't use. With Luigi's comment, I wonder that there isn't an = mbuf_list structure already we can just steal. it could almost be the = current interface input queue structure. The exact details don't matter; what does matter is that we make it as = easy as possible to detect mistakes using the compiler (e.g., queue = passed where mbuf expected, or vice versa) and that those situations we = can't check statically, we try to check dynamically (multi-entry queue = passed where mbuf expected). In the past we've had bugs along similar = lines, where code expects m->m_nextpkt to be NULL when it isn't leading = to very unhappy times in socket buffers, etc. Ideally what we did would = have no expense at runtime unless debugging features were turned on = (INVARIANTS). Robert=