From owner-freebsd-arch@FreeBSD.ORG Sat Nov 23 10:57:33 2013 Return-Path: Delivered-To: freebsd-arch@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 E365CDCD; Sat, 23 Nov 2013 10:57:32 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id BD1DC223F; Sat, 23 Nov 2013 10:57:32 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [198.74.231.63]) by cyrus.watson.org (Postfix) with ESMTPS id 61B7C46B3C; Sat, 23 Nov 2013 05:57:32 -0500 (EST) Date: Sat, 23 Nov 2013 10:57:31 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer Subject: Re: svn commit: r258328 - head/sys/net In-Reply-To: <528D6173.4080406@freebsd.org> Message-ID: References: <201311182258.rAIMwEFd048783@svn.freebsd.org> <528D6173.4080406@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Adrian Chadd , "src-committers@freebsd.org" , FreeBSD Net , "svn-src-all@freebsd.org" , "George V. Neville-Neil" , "freebsd-arch@freebsd.org" , "svn-src-head@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Nov 2013 10:57:33 -0000 On Wed, 20 Nov 2013, Julian Elischer wrote: >> After that it'd be nice to write a set of mbuf list macros for abstract the >> whole queue, dequeue, concat, iterate, etc (like sys/queue.h, but for >> mbufs.) >> >> What do people think? >> >> (I've been doing it for m->next chained things, but not m->m_nextpkt >> things..) > > I was thinking: new interfaces.. (your -multi names sound good). macros for > handling said lists so that people don't screw them up Old drivers run with > no change. To me, the name "multi" is ambiguous: could be multicast. If we call the new datastructure "mbqueue" or "mqueue", then we should name the method ether_input_mbqueue or ether_input_mqueue. Robert > >> >> >> >> -adrian >> >> >> On 18 November 2013 14:58, George V. Neville-Neil wrote: >>> Author: gnn >>> Date: Mon Nov 18 22:58:14 2013 >>> New Revision: 258328 >>> URL: http://svnweb.freebsd.org/changeset/base/258328 >>> >>> Log: >>> Allow ethernet drivers to pass in packets connected via the nextpkt >>> pointer. >>> Handling packets in this way allows drivers to amortize work during >>> packet reception. >>> >>> Submitted by: Vijay Singh >>> Sponsored by: NetApp >>> >>> Modified: >>> head/sys/net/if_ethersubr.c >>> >>> Modified: head/sys/net/if_ethersubr.c >>> ============================================================================== >>> --- head/sys/net/if_ethersubr.c Mon Nov 18 22:55:50 2013 (r258327) >>> +++ head/sys/net/if_ethersubr.c Mon Nov 18 22:58:14 2013 (r258328) >>> @@ -708,13 +708,25 @@ static void >>> ether_input(struct ifnet *ifp, struct mbuf *m) >>> { >>> >>> + struct mbuf *mn; >>> + >>> /* >>> - * We will rely on rcvif being set properly in the deferred >>> context, >>> - * so assert it is correct here. >>> + * The drivers are allowed to pass in a chain of packets linked >>> with >>> + * m_nextpkt. We split them up into separate packets here and pass >>> + * them up. This allows the drivers to amortize the receive lock. >>> */ >>> - KASSERT(m->m_pkthdr.rcvif == ifp, ("%s: ifnet mismatch", >>> __func__)); >>> + while (m) { >>> + mn = m->m_nextpkt; >>> + m->m_nextpkt = NULL; >>> >>> - netisr_dispatch(NETISR_ETHER, m); >>> + /* >>> + * We will rely on rcvif being set properly in the >>> deferred context, >>> + * so assert it is correct here. >>> + */ >>> + KASSERT(m->m_pkthdr.rcvif == ifp, ("%s: ifnet mismatch", >>> __func__)); >>> + netisr_dispatch(NETISR_ETHER, m); >>> + m = mn; >>> + } >>> } >>> >>> /* > >