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?

> 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 :)

> > 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.

> 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 catch up.

> And if someone were to update the NetBSD altq with what appears to be
> -current ALTQ from KAME, there would be no need for pf, right ?

Right, it doesn't work with pf at the moment.
And I don't intend to simply import the ALTQ code as is from OpenBSD.

> Hopefully this means any integration/API between packet classifiers
> and ALTQ is still open for discussion :)

Yes, it has been and will be always open for discussion :)

-Kenjiro