On 4/4/07, YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp> wrote:
> > On Mon, Mar 26, 2007 at 05:59:20PM +0200, Martin Husemann wrote:
> > >  - There should not be a new token field in mbufs, just use m_tag(9)
> >
> > I would explicitly discourage m_tag. The overhead of maintaining another
> > two allocations per packet is IMO completely wrong. It was nice during
> > initial development of some subsystems, it is also useful for large
> > allocations like IPsec does, but in general firewalls and ALTQ should
> > get a few bytes in the packet header for this.
> >
> > I tried that in DragonFly and it actually simplified e.g. PF quite a
> > bit.
> >
> > Joerg
>
> how about tweaking m_tag api so that a few small tags can be allocated from
> embedded storage in mbuf automatically?
>
> YAMAMOTO Takashi
>

The m_tag API allows one to embed metadata information in the packets
(aka mbufs). As far as I know, it is already used by the VLAN
accelerator. I think the idea of of using a few definite types of
m_tags type of fixed size is simpler than allowing arbitrary metadata
sizes. Also, the information can be placed in the mbuf headers.
However, if a packet has been tagged with multiple tags, how do we
order the tags? Also, tags can be grouped into categories. Do we allow
ordering across groups or restrict ourselves within the groups only? I
think the best way is to overhaul the m_tag API (looks like YAMAMOTO
be in seconds with this). We can have APIs that order the tags,
inserts tags, deletes tags, .....This would also be a good time to do
away with the circular link list and move to a hash based approach..

Thanks,
Sourav