From owner-freebsd-arch@FreeBSD.ORG Wed Nov 20 22:02:28 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED356308; Wed, 20 Nov 2013 22:02:27 +0000 (UTC) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5915D2CCC; Wed, 20 Nov 2013 22:02:27 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id i13so2574116qae.3 for ; Wed, 20 Nov 2013 14:02:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=HQFZhn/dLqkdw1iISOkod7K0WU/e+sX2vtPWRWn3csw=; b=FrEz4seDFuHpbprYomYXLQuE9UOhnywGQgvic2EH8H74GdrxF5vWx30NcMsVRD13w2 33W+VzQO+Sm6fe2B8kad/8LKNO4g+96dmxd++l2MH5hyrHwd4XSo2LMNSRK86Vg6hgoc lSx+lrOupDE0nt0AgxX57W2VrkIyU8EWkP4v5NcD8NdAwWzetnr02Kz0T8opNI11bkmJ V3xs1GsFEmQKjjjMmmBBfCIXSj2n3l4bXIvzxMaxkZraYMN/VQ3200bEifhZ0cz8ZoS2 bqPz2OA1jghdmbFOy17kV5NHxSEMPcn2FsG7v5LX7TZ5WEkIbeUJd0IABcULvI6w9gwp 8tXw== MIME-Version: 1.0 X-Received: by 10.224.64.200 with SMTP id f8mr5675355qai.55.1384984946603; Wed, 20 Nov 2013 14:02:26 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Wed, 20 Nov 2013 14:02:26 -0800 (PST) In-Reply-To: <201311182258.rAIMwEFd048783@svn.freebsd.org> References: <201311182258.rAIMwEFd048783@svn.freebsd.org> Date: Wed, 20 Nov 2013 14:02:26 -0800 X-Google-Sender-Auth: ki1OX3h-CVp1suO6clamTiMqGqo Message-ID: Subject: Re: svn commit: r258328 - head/sys/net From: Adrian Chadd To: "George V. Neville-Neil" , "freebsd-arch@freebsd.org" , FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 Cc: "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , "src-committers@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: Wed, 20 Nov 2013 22:02:28 -0000 Can we revert this and just quickly put together something else that won't potentially come back to bite us with weird side effects? My suggestions (and I'm happy to do this work if needed): * create a lightweight mbuf queue representation so an mbuf list isn't just the mbuf header pointer; * create a new ether input (say, ether_input_multi) that takes an mbuf list, so existing driver code does the right thing. 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..) -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; > + } > } > > /* From owner-freebsd-arch@FreeBSD.ORG Wed Nov 20 22:29:56 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AE8E9D27; Wed, 20 Nov 2013 22:29:56 +0000 (UTC) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7E2AB2E11; Wed, 20 Nov 2013 22:29:56 +0000 (UTC) Received: from [209.249.190.124] (port=55801 helo=gnnmac.hudson-trading.com) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VjGHP-0008Qy-E7; Wed, 20 Nov 2013 17:29:53 -0500 Content-Type: multipart/signed; boundary="Apple-Mail=_E7352C3B-1624-44C1-8794-7B37258E98DD"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: svn commit: r258328 - head/sys/net From: George Neville-Neil In-Reply-To: Date: Wed, 20 Nov 2013 17:29:37 -0500 Message-Id: <023E719B-1059-4670-8556-EBAC18A2F007@freebsd.org> References: <201311182258.rAIMwEFd048783@svn.freebsd.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1822) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freebsd.org X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com Cc: "svn-src-head@freebsd.org" , FreeBSD Net , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" , "freebsd-arch@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: Wed, 20 Nov 2013 22:29:56 -0000 --Apple-Mail=_E7352C3B-1624-44C1-8794-7B37258E98DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 20, 2013, at 17:02 , Adrian Chadd wrote: > Can we revert this and just quickly put together something else that > won't potentially come back to bite us with weird side effects? >=20 > My suggestions (and I'm happy to do this work if needed): >=20 > * create a lightweight mbuf queue representation so an mbuf list isn't > just the mbuf header pointer; > * create a new ether input (say, ether_input_multi) that takes an mbuf > list, so existing driver code does the right thing. >=20 > 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.) >=20 > What do people think? >=20 > (I've been doing it for m->next chained things, but not m->m_nextpkt = things..) I think the right way to do this is to move forwards and not backwards. This change has the nice effect of not breaking anything else in the tree while providing us with a feature that will be useful. =20 If you want to add an ether_input_multi() that might make sense as an adjunct to what=92s there now. Best, Geoge =20 --Apple-Mail=_E7352C3B-1624-44C1-8794-7B37258E98DD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlKNN9EACgkQYdh2wUQKM9IhNwCgxNJQY383jR+pHPAg6DuJc4/a O4wAnirp4BKvFIPw48tB7ddl+po7Fb2G =YkRf -----END PGP SIGNATURE----- --Apple-Mail=_E7352C3B-1624-44C1-8794-7B37258E98DD-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 21 00:00:36 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2CD4CAE0; Thu, 21 Nov 2013 00:00:36 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id E0D552317; Thu, 21 Nov 2013 00:00:34 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 6093F7300A; Thu, 21 Nov 2013 01:02:45 +0100 (CET) Date: Thu, 21 Nov 2013 01:02:45 +0100 From: Luigi Rizzo To: George Neville-Neil Subject: Re: svn commit: r258328 - head/sys/net Message-ID: <20131121000245.GA30549@onelab2.iet.unipi.it> References: <201311182258.rAIMwEFd048783@svn.freebsd.org> <023E719B-1059-4670-8556-EBAC18A2F007@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <023E719B-1059-4670-8556-EBAC18A2F007@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Adrian Chadd , "src-committers@freebsd.org" , FreeBSD Net , "svn-src-all@freebsd.org" , "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: Thu, 21 Nov 2013 00:00:36 -0000 On Wed, Nov 20, 2013 at 05:29:37PM -0500, George Neville-Neil wrote: > > On Nov 20, 2013, at 17:02 , Adrian Chadd wrote: > > > Can we revert this and just quickly put together something else that > > won't potentially come back to bite us with weird side effects? > > > > My suggestions (and I'm happy to do this work if needed): > > > > * create a lightweight mbuf queue representation so an mbuf list isn't > > just the mbuf header pointer; > > * create a new ether input (say, ether_input_multi) that takes an mbuf > > list, so existing driver code does the right thing. > > > > 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 think the right way to do this is to move forwards and not backwards. > This change has the nice effect of not breaking anything else in the > tree while providing us with a feature that will be useful. I am a bit torn on this. George is right - we should move forward, and we have been discussing this trivial change for two years. It is impossible to tell when someone will find the time to implement the mbuf queue and the new method (more on this later). So we should not back it out. At the same time: in principle this change does not break anything, but Robert is right that some of the 50-100 drivers we have might forget to clear m_nextpkt and cause trouble. So it would be nice to implement some protection, maybe something as simple as setting a flag in the first mbuf to tell that this is a chain and not a single mbuf. We have 12 M_PROTO* flags to use. For the next step: I am still wondering what is the best way to implement an alternate ifp->if_input_multi method (which takes an mbuf queue as an argument, and can be checked by the compiler). I am not too fond of having two different input methods, as it complicates life when one has to intercept packets. On the other hand, globally changing all drivers to use the if_input_multi() method is too much trouble, so i suspect we will have to come up with some nice trick, e.g. use a pseudo mbuf with m_type = MT_MBQUEUE and overload the m_hdr fields as queue pointers. cheers luigi From owner-freebsd-arch@FreeBSD.ORG Thu Nov 21 00:07:09 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 67CBCE2D; Thu, 21 Nov 2013 00:07:09 +0000 (UTC) Received: from mail-qe0-x235.google.com (mail-qe0-x235.google.com [IPv6:2607:f8b0:400d:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C7EDF236D; Thu, 21 Nov 2013 00:07:08 +0000 (UTC) Received: by mail-qe0-f53.google.com with SMTP id cy11so6858980qeb.12 for ; Wed, 20 Nov 2013 16:07:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=KajDMffiIXncp1WKPF9oXTEogDIzTZoJnsZewsmr2v8=; b=bb5uCOqzwFDPLeDtWrLPQHTspQiCQw/FjzDGq5dn2zznM8FsTnKl3FJ07qJtLqm3rp LdBs86y1eJy/W/dqUUskphKO8PC474dmlUkIX18/qZBCwxjes6SLZ6kD6pDvGgy/h5bI dYHKtz2iy1z+5n473RgGIkMOHnG1V47UcdKnS30VRYU3CvvdK17JzY472PAwazvv4eWc +UdSxZ4R9tlbgJaky1FNSfTW5XkBKWsoxWRmFAnvbQPe3Ug5fBZs1S37ugy80BjRPd60 B0eAUBElEVAaEEwafM5IAh2qOplByAReAvVzbD7QjT5KFbjcJc8y9iK+C1IRVHBkFhLO uD6A== MIME-Version: 1.0 X-Received: by 10.224.12.10 with SMTP id v10mr6394090qav.98.1384992427830; Wed, 20 Nov 2013 16:07:07 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Wed, 20 Nov 2013 16:07:07 -0800 (PST) In-Reply-To: <20131121000245.GA30549@onelab2.iet.unipi.it> References: <201311182258.rAIMwEFd048783@svn.freebsd.org> <023E719B-1059-4670-8556-EBAC18A2F007@freebsd.org> <20131121000245.GA30549@onelab2.iet.unipi.it> Date: Wed, 20 Nov 2013 16:07:07 -0800 X-Google-Sender-Auth: WL_16bDMg3EIC-et8hOOltYtOIc Message-ID: Subject: Re: svn commit: r258328 - head/sys/net From: Adrian Chadd To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: "src-committers@freebsd.org" , FreeBSD Net , "svn-src-all@freebsd.org" , George 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: Thu, 21 Nov 2013 00:07:09 -0000 Hi, We should migrate drivers to use a multi-input method where it's appropriate. It's the same pain as if_transmit() is/was. I'd really like to avoid having hacky solutions like mbufs with magic types. If we're going down that path, we should create a correct inline messaging mechanism that includes arbitrary messages in the stream, where some may or may not be mbufs. Magic mbufs just makes me want to tear out my eyes a little. So, the reason I'd like to back it out is because we should be doing it via a multi method with some type that represents an mbuf list. If George doesn't mind, I'll add a multi input method, move this stuff into it, and make ether_input just be single frames. -adrian From owner-freebsd-arch@FreeBSD.ORG Thu Nov 21 00:32:49 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 999C24C2; Thu, 21 Nov 2013 00:32:49 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 56CEF24EB; Thu, 21 Nov 2013 00:32:49 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 975807300A; Thu, 21 Nov 2013 01:35:06 +0100 (CET) Date: Thu, 21 Nov 2013 01:35:06 +0100 From: Luigi Rizzo To: Adrian Chadd Subject: Re: svn commit: r258328 - head/sys/net Message-ID: <20131121003506.GA30962@onelab2.iet.unipi.it> References: <201311182258.rAIMwEFd048783@svn.freebsd.org> <023E719B-1059-4670-8556-EBAC18A2F007@freebsd.org> <20131121000245.GA30549@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "src-committers@freebsd.org" , FreeBSD Net , "svn-src-all@freebsd.org" , George 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: Thu, 21 Nov 2013 00:32:49 -0000 On Wed, Nov 20, 2013 at 04:07:07PM -0800, Adrian Chadd wrote: > Hi, > > We should migrate drivers to use a multi-input method where it's > appropriate. It's the same pain as if_transmit() is/was. right, and i think that is very confusing and i'd rather not replicate the experience. But what is your plan, have both if_input and if_input_multi ? And then make the vlan and all similar filters intercept both ? Because all of the existing options have pros and cons: 1. having both if_input and if_input_multi is visually cleaner but requires extending ifnet and some convoluted code in the initialization (same as if_transmit) 2. just if_input with typed mbufs is less clean but has the big advantage thay you only need to change ether_input() (and equivalent for other L2 protocols), and it is not error prone 3. having only if_input_multi (even without renaming if_input) requires you to change all the 100+ drivers. It seems to me that #2 at least preserves binary compatibility with driver modules and is easier to backport to other versions of FreeBSD, this is why i prefer it. my two cents... cheers luigi > I'd really like to avoid having hacky solutions like mbufs with magic > types. If we're going down that path, we should create a correct > inline messaging mechanism that includes arbitrary messages in the > stream, where some may or may not be mbufs. Magic mbufs just makes me > want to tear out my eyes a little. > > So, the reason I'd like to back it out is because we should be doing > it via a multi method with some type that represents an mbuf list. If > George doesn't mind, I'll add a multi input method, move this stuff > into it, and make ether_input just be single frames. > > > > -adrian From owner-freebsd-arch@FreeBSD.ORG Thu Nov 21 01:27:24 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 720F0200; Thu, 21 Nov 2013 01:27:24 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DEF0E2754; Thu, 21 Nov 2013 01:27:23 +0000 (UTC) Received: from julian-mbp3.pixel8networks.com (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id rAL1RKmp006812 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 20 Nov 2013 17:27:22 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <528D6173.4080406@freebsd.org> Date: Wed, 20 Nov 2013 17:27:15 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Adrian Chadd , "George V. Neville-Neil" , "freebsd-arch@freebsd.org" , FreeBSD Net Subject: Re: svn commit: r258328 - head/sys/net References: <201311182258.rAIMwEFd048783@svn.freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , "src-committers@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: Thu, 21 Nov 2013 01:27:24 -0000 On 11/20/13, 2:02 PM, Adrian Chadd wrote: > Can we revert this and just quickly put together something else that > won't potentially come back to bite us with weird side effects? > > My suggestions (and I'm happy to do this work if needed): > > * create a lightweight mbuf queue representation so an mbuf list isn't > just the mbuf header pointer; > * create a new ether input (say, ether_input_multi) that takes an mbuf > list, so existing driver code does the right thing. > > 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. > > > > -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; >> + } >> } >> >> /* From owner-freebsd-arch@FreeBSD.ORG Thu Nov 21 01:31:53 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 99B77523; Thu, 21 Nov 2013 01:31:53 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6008327A0; Thu, 21 Nov 2013 01:31:53 +0000 (UTC) Received: from julian-mbp3.pixel8networks.com (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id rAL1Vku3006851 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 20 Nov 2013 17:31:47 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <528D627D.2020009@freebsd.org> Date: Wed, 20 Nov 2013 17:31:41 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Luigi Rizzo , Adrian Chadd Subject: Re: svn commit: r258328 - head/sys/net References: <201311182258.rAIMwEFd048783@svn.freebsd.org> <023E719B-1059-4670-8556-EBAC18A2F007@freebsd.org> <20131121000245.GA30549@onelab2.iet.unipi.it> <20131121003506.GA30962@onelab2.iet.unipi.it> In-Reply-To: <20131121003506.GA30962@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "src-committers@freebsd.org" , FreeBSD Net , "svn-src-all@freebsd.org" , George 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: Thu, 21 Nov 2013 01:31:53 -0000 On 11/20/13, 4:35 PM, Luigi Rizzo wrote: > On Wed, Nov 20, 2013 at 04:07:07PM -0800, Adrian Chadd wrote: >> Hi, >> >> We should migrate drivers to use a multi-input method where it's >> appropriate. It's the same pain as if_transmit() is/was. > right, and i think that is very confusing and i'd rather > not replicate the experience. > > But what is your plan, have both if_input and if_input_multi ? > And then make the vlan and all similar filters intercept both ? > Because all of the existing options have pros and cons: > > 1. having both if_input and if_input_multi is visually cleaner > but requires extending ifnet and some convoluted code in the > initialization (same as if_transmit) > > 2. just if_input with typed mbufs is less clean but has the big > advantage thay you only need to change ether_input() (and equivalent > for other L2 protocols), and it is not error prone if_input_multi() or whatever it is called is just this patch split into two bits. in the simple case it just calls the single one multiple times, just like this patch does. it is clean from teh compiler's point of view, > > 3. having only if_input_multi (even without renaming if_input) > requires you to change all the 100+ drivers. > > It seems to me that #2 at least preserves binary compatibility > with driver modules and is easier to backport to other versions > of FreeBSD, this is why i prefer it. > > my two cents... > > cheers > luigi > >> I'd really like to avoid having hacky solutions like mbufs with magic >> types. If we're going down that path, we should create a correct >> inline messaging mechanism that includes arbitrary messages in the >> stream, where some may or may not be mbufs. Magic mbufs just makes me >> want to tear out my eyes a little. >> >> So, the reason I'd like to back it out is because we should be doing >> it via a multi method with some type that represents an mbuf list. If >> George doesn't mind, I'll add a multi input method, move this stuff >> into it, and make ether_input just be single frames. >> >> >> >> -adrian > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Thu Nov 21 14:36:28 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C01DA1D9; Thu, 21 Nov 2013 14:36:28 +0000 (UTC) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 308832B87; Thu, 21 Nov 2013 14:36:27 +0000 (UTC) Received: by mail-la0-f43.google.com with SMTP id n7so8595584lam.16 for ; Thu, 21 Nov 2013 06:36:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=VaVxEoUPpZNrmL8zcobT0aB48Mi+hvla+bWrEHYteMo=; b=BurAQuIngXdOcdketejPR7elj5w0MY3hoCyCzMhvbvSzuqm7TN1GBcQjAdgUTgzvIn s/gsQdjTUnW7KNALsYFNAgtheZXbq3PcATRk0h7fznzK1suM+cYHQ+BSQzaxq0lRckP7 zOV+mHt3qS2zuK4yN9VMNI7VaxanbbIZ2J/VwuqUxXYnerOvZAPZrP1RdqUtrteMhFDu OItCvwsXA2/o1Q0ubBEv8wFfSTx0tevd6m0eUVdr2n6UbBfpCxXUzXa5hfSHD6FUI0OD D9W0i5UFKMFnD9N+dRIY6yM/Hm+ylgmEJDbw/oJfUUSB9WAkVxG9eagn8wqFYrE1L74g MxPw== X-Received: by 10.112.150.103 with SMTP id uh7mr2039905lbb.34.1385044585178; Thu, 21 Nov 2013 06:36:25 -0800 (PST) Received: from [192.168.2.30] ([2.176.162.77]) by mx.google.com with ESMTPSA id vz9sm23479590lbb.17.2013.11.21.06.36.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Nov 2013 06:36:24 -0800 (PST) Message-ID: <528E1A83.7070509@gmail.com> Date: Thu, 21 Nov 2013 18:06:51 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: svn commit: r258328 - head/sys/net References: <201311182258.rAIMwEFd048783@svn.freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "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: Thu, 21 Nov 2013 14:36:28 -0000 On 11/21/2013 1:32 AM, Adrian Chadd wrote: > Can we revert this and just quickly put together something else that > won't potentially come back to bite us with weird side effects? > > My suggestions (and I'm happy to do this work if needed): > > * create a lightweight mbuf queue representation so an mbuf list isn't > just the mbuf header pointer; > * create a new ether input (say, ether_input_multi) that takes an mbuf > list, so existing driver code does the right thing. > > 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..) > > > > -adrian > > > What are possible sideeffects? What are the benefits we achieve by a distinct queue structure and having both if_input and if_input_multi? -- Best regards. Hooman Fazaeli From owner-freebsd-arch@FreeBSD.ORG Thu Nov 21 20:27:26 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 89427F14; Thu, 21 Nov 2013 20:27:26 +0000 (UTC) Received: from mail-qe0-x234.google.com (mail-qe0-x234.google.com [IPv6:2607:f8b0:400d:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E84912331; Thu, 21 Nov 2013 20:27:25 +0000 (UTC) Received: by mail-qe0-f52.google.com with SMTP id ne12so225806qeb.25 for ; Thu, 21 Nov 2013 12:27:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=rVgtVdKNVGHJJXvnnjh8Lu0bJyME0SRoO5j6+SiROAM=; b=016dqiEySlUq3jx/zYzuzOGlS455QON0BUUqCdFrrBFCnxw3idNEP32VzDdii4mN2U YYFKuXV2HyInaqZTgMU4t6nQQf0zOUqhLkdOV4aFz2NQ+b9MIbt8Id3VPWUyBEZc5AcB 1jG4rHFmIW+c8x+q9fZUkDWRE3+KZ6+Bk9scn8FIcUIuag5fJQ2Axbp+hUjlWvVwP2br vJUUofbnqs1rUilvsXpcSuJpM2uFpM3CnbpQ++JLWWZlyvKJw2pizkb6mhJKx9SOHsLH Im6W4r7PzZXxlcKR/IHxRMdri3plEBKhskqPhZdoknuD1oJFBK7lyo7iQPMLEaP0walF wvUw== MIME-Version: 1.0 X-Received: by 10.224.12.10 with SMTP id v10mr14737114qav.98.1385065645153; Thu, 21 Nov 2013 12:27:25 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Thu, 21 Nov 2013 12:27:25 -0800 (PST) In-Reply-To: <528E1A83.7070509@gmail.com> References: <201311182258.rAIMwEFd048783@svn.freebsd.org> <528E1A83.7070509@gmail.com> Date: Thu, 21 Nov 2013 12:27:25 -0800 X-Google-Sender-Auth: RV0JYfXTj1fTPfmfag55WipDIHw Message-ID: Subject: Re: svn commit: r258328 - head/sys/net From: Adrian Chadd To: Hooman Fazaeli Content-Type: text/plain; charset=ISO-8859-1 Cc: "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: Thu, 21 Nov 2013 20:27:26 -0000 On 21 November 2013 06:36, Hooman Fazaeli wrote: > What are possible sideeffects? What are the benefits we achieve by a > distinct > queue structure and having both if_input and if_input_multi? Doing incremental development where you can minimise unintended side-effects during development? -adrian From owner-freebsd-arch@FreeBSD.ORG Fri Nov 22 11:32:27 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 1A681B8 for ; Fri, 22 Nov 2013 11:32:27 +0000 (UTC) Received: from mail-ob0-x246.google.com (mail-ob0-x246.google.com [IPv6:2607:f8b0:4003:c01::246]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DF7A72CA1 for ; Fri, 22 Nov 2013 11:32:26 +0000 (UTC) Received: by mail-ob0-f198.google.com with SMTP id wo20so3406250obc.5 for ; Fri, 22 Nov 2013 03:32:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:message-id:date:subject:from:to:content-type; bh=DpXCh1szzKCY+F7WcSE0ld/DTUHxniswXgJsGvDU0VU=; b=uaLODbb2sWa+Va0ASmNdcjg1CotIRnWUItd4f6ZSVdXGEpRb3oLUk3yhhMB2HFC+/1 KGh9b3UDY9iJGxYC8ubGYNMFOFEFntgMou5/tX22s4JAOYfsu3tS0VT0XYt+aX9wnmVo MgRKU4apK6iDLJYLLO85L0CQ8Rs86FiqmVG99F/WEf1hECkcOYU9Pqy6qxbZ1I+ANnb9 lHLjML5RQ7Jtr4h4oY1GiysGEfXYJam43eAZcbppbs+sBcD4/7n6TITxJskWinpmryod uA7CMc8taXDDaqS80MF2G5Wyy6AMxHci8rRek6H7KNEv0qDMqVzp9Kk4E9HA0dF7RTbz Y/JQ== MIME-Version: 1.0 X-Received: by 10.182.129.227 with SMTP id nz3mr3939792obb.25.1385119946269; Fri, 22 Nov 2013 03:32:26 -0800 (PST) Message-ID: <089e01536a9c5e6bd404ebc25e81@google.com> Date: Fri, 22 Nov 2013 11:32:26 +0000 Subject: www.freebsd.org From: Ciara Millar To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.16 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: Fri, 22 Nov 2013 11:32:27 -0000 PGRpdiBkaXI9Imx0ciI+PHNwYW4gIA0Kc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLHNhbnMtc2Vy aWY7Zm9udC1zaXplOjEzcHgiPkhpLDwvc3Bhbj48YnIgIA0Kc3R5bGU9ImZvbnQtZmFtaWx5OmFy aWFsLHNhbnMtc2VyaWY7Zm9udC1zaXplOjEzcHgiPjxkaXYgIA0KY2xhc3M9ImdtYWlsX3F1b3Rl IiAgDQpzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6MTNweCI+ PGRpdiB0ZXh0PSIjMDAwMDAwIiAgDQpiZ2NvbG9yPSIjRkZGRkZGIj4NCjxkaXY+PHA+SSBjYW1l IGFjcm9zcyB5b3VyIHdlYnNpdGUgYW5kIHdhbnRlZCB0byBzZW5kIHlvdSBhIHF1aWNrIG5vdGUu ICANCldpdGggYSBmZXcgc2ltcGxlIGNoYW5nZXMgdG8gbWFrZSB5b3VyIHNpdGUgbW9yZSBTRU8t ZnJpZW5kbHkgSZJtIHN1cmUgeW91ICANCmNhbiBjb252ZXJ0IG1vcmUgdmlzaXRvcnMgaW50byBs ZWFkcyBhbmQgZ2V0IGl0IHBsYWNlZCBoaWdoZXIgaW4gdGhlICANCm9yZ2FuaWMgc2VhcmNoIHJl c3VsdHMsIGZvciBrZXl3b3JkcyB0aGF0IG1hdHRlciB0byB5b3UgdGhlIG1vc3QuPC9wPg0KPC9k aXY+PGRpdj48cD5XZZJyZSBhbiBBdXN0cmFsaWFuIGJhc2VkIGNvbXBhbnkgd2l0aCBhIGdyZWF0 IGluLWhvdXNlICANCnRlY2huaWNhbCB0ZWFtIHdobyByZWFsbHkga25vdyB0aGVpciBzdHVmZiBh Ym91dCBzZWFyY2ggZW5naW5lICANCm9wdGltaXphdGlvbi6gPC9wPjwvZGl2PjxkaXY+PHA+V291 bGQgeW91IGxpa2UgYSBiaXQgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCAgDQpob3cgdG8gZ2l2ZSB5 b3VyIHdlYnNpdGUgYSBib29zdCB3aXRoIGJldHRlciBTRU8/PGJyPg0KPC9wPjwvZGl2PjxkaXY+ PHA+oDwvcD48L2Rpdj48ZGl2PjxwPkJlc3QgUmVnYXJkczwvcD48L2Rpdj48ZGl2PjxwPkNpYXJh ICANCk1pbGxhcjxicj5TRU8vV2ViIFNwZWNpYWxpc3Q8L3A+PC9kaXY+PGRpdj48L2Rpdj48ZGl2 PjxzcGFuICANCnN0eWxlPSJmb250LXNpemU6Ny41cHQiPjwvc3Bhbj48cD48Yj48c3BhbiAgDQpz dHlsZT0iZm9udC1zaXplOjcuNXB0O2NvbG9yOnJnYigxMTEsMTY4LDIyMCkiPkFVUyBIZWFkcXVh cnRlcjxicj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtjb2xvcjpy Z2IoMTExLDE2OCwyMjApIj5BdXN0cmFsaWFuICANClRlY2hub2xvZ3kgUGFyaywgTG9jb21vdGl2 ZSBTdHJlZXQsIEV2ZWxlaWdooDxicj5OU1cgIA0KMjAxNTxicj48Yj48YnI+SW50ZXJuYXRpb25h bCBIZWFkcXVhcnRlcjxicj48L2I+NTAxIDE5dGggU3RyZWV0LCBOLlcuLCAgDQpXYXNoaW5ndG9u LCBELkMuIDIwNDMxPC9zcGFuPjwvcD4NCjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2Pg0K From owner-freebsd-arch@FreeBSD.ORG Sat Nov 23 10:55:42 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 760B4B46; Sat, 23 Nov 2013 10:55:42 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 4ED41221F; Sat, 23 Nov 2013 10:55:42 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [198.74.231.63]) by cyrus.watson.org (Postfix) with ESMTPS id 4614146B3C; Sat, 23 Nov 2013 05:55:35 -0500 (EST) Date: Sat, 23 Nov 2013 10:55:34 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Adrian Chadd Subject: Re: svn commit: r258328 - head/sys/net In-Reply-To: Message-ID: References: <201311182258.rAIMwEFd048783@svn.freebsd.org> <023E719B-1059-4670-8556-EBAC18A2F007@freebsd.org> <20131121000245.GA30549@onelab2.iet.unipi.it> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "src-committers@freebsd.org" , FreeBSD Net , "svn-src-all@freebsd.org" , George 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:55:42 -0000 On Wed, 20 Nov 2013, Adrian Chadd wrote: > We should migrate drivers to use a multi-input method where it's > appropriate. It's the same pain as if_transmit() is/was. > > I'd really like to avoid having hacky solutions like mbufs with magic types. > If we're going down that path, we should create a correct inline messaging > mechanism that includes arbitrary messages in the stream, where some may or > may not be mbufs. Magic mbufs just makes me want to tear out my eyes a > little. > > So, the reason I'd like to back it out is because we should be doing it via > a multi method with some type that represents an mbuf list. If George > doesn't mind, I'll add a multi input method, move this stuff into it, and > make ether_input just be single frames. My worry here is that the failure modes for easy oversights and bugs are quite subtle ones: mbuf leakage and data corruption. Our goal should be to shift as many as possible of those bugs to compiler-detected events (e.g., due to type checking), or where not possible, run-time detected events (e.g., due to easily detected non-NULL pointers). I'm OK with the current change staying in the tree for a few weeks on the path there, but I much prefer the world in which we use different symbols for different "types". This is especially important if we will have device driver vendors maintaining drivers across many versions (which we do): we really don't want a driver using ether_input for queue handoff in 11.x to just mysteriously leak mbufs in 10.x. Instead, the driver should fail to compile. Robert 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; >>> + } >>> } >>> >>> /* > >