Date: Wed, 20 Nov 2013 12:11:20 -0800 From: Julian Elischer <julian@freebsd.org> To: Robert Watson <rwatson@FreeBSD.org>, "George V. Neville-Neil" <gnn@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r258328 - head/sys/net Message-ID: <528D1768.9000401@freebsd.org> In-Reply-To: <alpine.BSF.2.00.1311191101060.50802@fledge.watson.org> References: <201311182258.rAIMwEFd048783@svn.freebsd.org> <alpine.BSF.2.00.1311191101060.50802@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/19/13, 3:04 AM, Robert Watson wrote:
> On Mon, 18 Nov 2013, George V. Neville-Neil wrote:
>
>> 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
>
> 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.,
>
> /*
> * 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;
> };
>
>
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?528D1768.9000401>