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
_______________________________________________
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"
