On 20 Nov 2013, at 20:11, Julian Elischer <jul...@freebsd.org> wrote:

>> 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.

The exact details don't matter; what does matter is that we make it as easy as 
possible to detect mistakes using the compiler (e.g., queue passed where mbuf 
expected, or vice versa) and that those situations we can't check statically, 
we try to check dynamically (multi-entry queue passed where mbuf expected). In 
the past we've had bugs along similar lines, where code expects m->m_nextpkt to 
be NULL when it isn't leading to very unhappy times in socket buffers, etc. 
Ideally what we did would have no expense at runtime unless debugging features 
were turned on (INVARIANTS).

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"

Reply via email to