Erik Nordmark wrote: > [EMAIL PROTECTED] wrote: > >> It's not just me who'd like this capability. >> >> At the very least, it would be desirable to add "something" to a >> packet receiving via pfhooks on the inbound side and be able to >> see that "something" again on the outbound side. > > > That is a much more well-defined problem. > > And with IP datapath refatoring in mind, it can be solved by passing > around an IP attribute as a procedure call argument inside IP. > > Things are easy if there is only one occupant of each pfhook. If there > can be multiple there has to be a way to name what the different > occupants use to that their corresponding piece on the outbound side > can find the right attribute. And that complexity is there independent > of the actual attribute mechanism.
Seperate to this but inline with the original subject... Everytime the networking code wants to know how long the packet is, it is necessary to call msgdsize() - or similar. In the best cast, this requires a simple bit of pointer arithmetic, but otherwise becomes a linked list walk. Costly. In BSD today the mbuf includes a "packet length" field in the first buffer and retrieving the length of the packet is as simple as "len = m->m_pkthdr.len" (or similar.) With respect to our networking stack, this would be the equivalent of the total amount of valid data in M_DATA dblks hung off of the mblk. Although there's a downside here (code that adjusts the length of a mblk chain needs to update this length field), the performance loss from that should be much less significant than the gain from not having to walk a linked list to know how long the packet is - in many places the call to msgdsize could also be eliminated. Imagine, "len = mb->db_dlen;" instead of "len = msgdsize(mb);". Darren _______________________________________________ networking-discuss mailing list [email protected]
