Date: Thu, 21 Nov 2013 18:06:51 +0330 From: Hooman Fazaeli <hoomanfazaeli@gmail.com> To: Adrian Chadd <adrian@freebsd.org> Cc: "src-committers@freebsd.org" <src-committers@freebsd.org>, FreeBSD Net <freebsd-net@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "George V. Neville-Neil" <gnn@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r258328 - head/sys/net Message-ID: <528E1A83.7070509@gmail.com> In-Reply-To: <CAJ-VmomjQrq39jafTTGQA_EJLSi5j%2BNB=g1sLwCK-KaEfgwrbw@mail.gmail.com> References: <201311182258.rAIMwEFd048783@svn.freebsd.org> <CAJ-VmomjQrq39jafTTGQA_EJLSi5j%2BNB=g1sLwCK-KaEfgwrbw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?528E1A83.7070509>