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