Erik Nordmark wrote: > [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?
Yes, it does. > The mblk manipulation has no such routine. Instead we have lots of > code that does > mp->b_rptr += sizeof (hdr); We do have adjmsg() that works for both +ve and -ve increments. Darren _______________________________________________ networking-discuss mailing list [email protected]
