Luigi Rizzo wrote:
>
> [Bcc to -net because it is relevant there. This email has been
> triggered by a private discussion i was having with other committers
> (who will easily recognise themselves :) which suggested the
> possibility of adding more fields to mbuf headers]
>
> Just recently came up to my attention that we have the following
> code in <sys/_label.h>
>
> #define MAC_MAX_POLICIES 4
> struct label {
> int l_flags;
> union {
> void *l_ptr;
> long l_long;
> } l_perpolicy[MAC_MAX_POLICIES];
> };
>
> (what are l_perpolicy[], ints ? Could this be written a bit better ?)
> and then in <sys/mbuf.h>
>
> struct pkthdr {
> struct ifnet *rcvif; /* rcv interface */
> int len; /* total packet length */
> /* variables for ip and tcp reassembly */
> void *header; /* pointer to packet header */
> /* variables for hardware checksum */
> int csum_flags; /* flags regarding checksum */
> int csum_data; /* data field used by csum routines */
> SLIST_HEAD(packet_tags, m_tag) tags; /* list of packet tags */
> struct label label; /* MAC label of data in packet */
> };
>
> The label is 5 ints, the pkthdr a total of 11 ints (and m_hdr takes
> another 6, for a total of 136 bytes of header info on 64-bit architectures).
>
> Of the pkthdr, only 3 fields (rcvif, len, tags) are of really general
> use, the rest being used only in certain cases and for very specific
> purposes (e.g. reassembly of fragments, or hw capabilities, or MAC).
>
> Now that Sam has done the excellent work of integrating packet tags
> to carry annotations around, i really believe that we should try
> to move out of the pkthdr all non-general fields, and move them to
> m_tags so we only pay the cost when needed and not in all cases.
> Also this pays a lot in terms of ABI compatibility and extensibility.
> I understand that for 5.0 it is a bit late to act, but i do hope
> that we can reconsider this issue for 5.1 and pull out of the pkthdr
> at least the MAC label, and possibly also the csum_* fields, much
> in the same way it has been done for VLAN labels.
Sounds good to me.
--
Andre
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
