Subject: Re: Try again, itojun, patches need more work.
To: Kenjiro Cho <kjc@csl.sony.co.jp>
From: Manuel Bouyer <bouyer@antioche.eu.org>
List: tech-net
Date: 06/30/2003 20:32:21
On Mon, Jun 30, 2003 at 01:41:54PM +0900, Kenjiro Cho wrote:
> 
> I'm a bit behind.  I haven't had much time to work on pf/ALTQ in
> kame/netbsd since itojun started working on pf's tagging a few days
> ago.
> pf's ALTQ in the kame/netbsd tree is not even working at the moment.
> So, I'll discuss technical details when the code becomes ready for
> review.
> 
> Here are some responses to general issues.
> 
> itojun and I have a consensus that using mbuf tagging is a way to go
> in order to replace the classifier in ipsec and ALTQ by a more
> complete external packet filter.

I suspect noone is complaining about this.

> The external packet filter we started with happens to be pf since
> itojun was inspired by pf's tagging which, in turn, is a byproduct of
> pf/altq integration.
> 
> But we cover different technical areas so that we had slightly
> different steps in mind.  itojun is more concerned about maintaining
> the KAME code on different platforms (KAME, netbsd, and openbsd).
> And I think everyone understands that itojun is trying to do it for
> common good, although people have different opinions on how the steps
> should be.  After all, merging the code to NetBSD is not the goal
> itself but a step for further evolution.
> 
> Regarding the API, ALTQ needs 2 independent APIs.  One for making use
> of an external packet filter as a classifer, and the other for
> configuring queues.
> The classifier part is fairly straightforward, and can be shared with
> other tag-user programs.

I think this is done with the move of the appropriate functions to
uipc_mbuf.c of the appropriate functions. We dissagree on the names but
it's not a big deal.

> 
> The queue setup part is specific to ALTQ and much more complex than
> the classifer part.  I originally thought not so many people would be
> interested in this part but apparently there are some.
> However, the current code is not so badly hard-coded into pf.
> Probably, Darren got that impression because the code uses the "pf"
> prefix for some structure and function names.  It was just to
> distinguish the newly introduced code fragments from the original
> ones.  The current ALTQ kernel code in OpenBSD is fairly independent
> of pf but I'm aware of a few issues to get resolved to make the API
> cleaner.

Would a registery mechanism similar to the tags be enouth for this ?
From my understanding, PF (and others packet classifiers when they'll be
available) only need to match a queue name with a tag, right ?

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 24 ans d'experience feront toujours la difference
--