Erik Berls wrote:
> itojun@iijlab.net writes:
> ] 	it was because ALTQ-on-1.6 inclueded its own packet classifier (which
> ] 	is very similar to packet filter).  in the way of ALTQ development,
> ] 	ALTQ dropped its classifier and chose to rely on packet tagging
> ] 	(provided by PF), because ALTQ classifier is basically a code
> ] 	duplication of packet filter.
> 
> So they decided to eliminate the ability to choose which packet
> filter the end user may utilize for the sake of skipping out on some
> work by piggybacking onto a codebase that is decidedly foreign to
> the NetBSD tree.
> 
> -=erik.

For ALTQ, it's a step forward from its home-brew classifier to
making use of external packet filters.
By this separation, the packet scheduler of ALTQ becomes independent
of packet classifiers, and possible to be used by any packet filter
capable of tagging mbufs.  (the integration of userland tools is
another story, though.)

The first external packet filter for ALTQ is pf.  pf is one of the
best packet filters, and still evolving rapidly.
More importantly, the pf people have been willing to collaborate with
us to integrate ALTQ.

So, it is possible to make ALTQ to work with ipf or other packet
filters in the future.  But, at this moment, it seems much easier to
just import pf for those who want to use pf-extended ALTQ.

This is from the view of ALTQ.  There are people interested in pf for
other reasons.

-Kenjiro