[EMAIL PROTECTED] wrote:
> Erik,
>
> One of the differences in how BSD uses the "length" is that it
> has a "special" mbuf that leads the chain of mbufs that has
> slightly less data storage space in lieu of other information
> if the M_PKTHDR flag is set.
>
> One of those fields in the extra information is a length field
> that covers the entire length of the chain. For single mbuf
> packets, this field equates to the data length also stored in it,
> but for multi-mbuf packets, the length stored in the "header"
> it is the sum.
>
> So the BSD mbuf can have:
>
> m->m_pkthdr.len == m->m_len
>
> for single mbuf packets and for multiple mbuf packets:
>
> m->m_pkthdr.len == msgdsize(m)
>
> Where the "m_len" is the equivalent of b_wptr - b_rptr.
>
> What Garret and I could see being advantageous is the
> m_pkthdr.len field being available, somehow.
If I don't misremeber I think BSD has a m_adj() call for dropping data
from an mbuf chain. Is that correct? And if so, does it adjust the above
length?
The mblk manipulation has no such routine. Instead we have lots of code
that does
mp->b_rptr += sizeof (hdr);
As I told you in person, I would be extremely concerned if we just
introduced some new b_len field and would require that all the code
magically correctly updated b_len when it changes b_rptr or b_wptr. Such
duplication of information would be quite likely to lead to a slew of bugs.
Such bugs can be avoided if we e.g., bit the bullet and *replaced b_wptr
with a new b_len field, since there wouldn't be such duplication. But
that would be an incompatbile change for all mblk using code.
So the question isn't whether it would be advantageous. The question is
about the cost/benefit tradeoff.
I understand that a length field would save some instructions (e.g., the
length of a single mblk can be retrieved with one load instruction
instead of two loads and a subtraction today). But I also think that any
code which repeatedly computes this in the key datapaths is a bit silly.
Erik
_______________________________________________
networking-discuss mailing list
[email protected]
