Date: Wed, 20 Nov 2013 12:12:53 -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: <528D17C5.6090006@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;
> };
>
> int
> ether_input(struct ifnet *ifp, struct mbuf_queue *m)
> {
>
> ...
> }
or separate entrypoints, old and and new
>
> ...
> struct mbuf_queue mq = { m };
>
> return (ether_input(ifp, &mq));
> ...
>
> That way the compiler can help us figure out where we expect an
> individual packet but have accidentally leaked a queue. Functions
> that accept only a single packet could also more agressively assert
> that m->m_nextpkt is NULL:
>
> M_ASSERT_ONEPACKET(m);
>
> Robert
>
>>
>>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?528D17C5.6090006>