In some mail from Kenjiro Cho, sie said:
> Darren Reed wrote:
> > Anyway, where
> > you are aiming to support a 1:N relationship, the "1" should be
> > providing the interface, not one of the N's.
> 
> If I have M:N relationship in mind where there are M packet schedulers
> and N packet filters, who should be providing the interface?

A middle layer.  That'd probably offend OpenBSD types, however,
because it'd make things marginally slower for the added benefit
of generality.  The implementation would involve things like altq
registering with some service provider that packet classifiers also
registered with, so the M:N bets split into M:1 and 1:N.

> > Maybe I'm just more concerned about things architecturally and looking
> > for a good design...
> 
> Maybe, sometimes I'm just more concerned about having things done at
> the right time with the given constraints :)

What time constraints ? :)

> > > The tagger and the consumer share only tag values.  All you need is a
> > > mechanism to map a string label to the corresponding tag value.
> > > In pf, pf creates and keeps mapping, and provides a function to
> > > retrieve tag values.
> > > 	u_int16_t pf_tagname2tag(char *tagname);
> > > So, if IPFilter provides a similar function, we can make use of
> > > IPFilter.
> > 
> > That suggests to me that IPFilter/pf couldn't co-exist if they were
> > both required to provide the same function name as part of an interface,
> > correct ?
> 
> You can provide ipf_tagname2tag() or whatever you want.
> Since it's not in the packet forwarding path, we can go through all
> the packet filters available on the system to look up the given tag.

What's the purpose for this?  My understanding of pf is that it turns a
packet tag name into a number inside the kernel to match up packets to
its rules.

So the packet is tagged as it enters the host and then altq matches up
its policies based on its tag configuration ?  Will defining queues,
etc, remain part of KAME or is it expected that this, too, is expected
by the packet classifier ? (pfctl has all this merged.)

You will have an interface to register (and deregister) functions that
resolve tag names in the altq code ?

> > Looking at ALTQ from KAME (I just did a cvs update from kame), there
> > is currently no use of m_tag that is found in the OpenBSD source.
> > Is this because changes are still pending being pulled up into KAME
> > from OpenBSD to support this ?
> 
> Right.  itojun imported pf into KAME today and started working on
> the setkey part.  I haven't had time to c