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
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
