Re: GSoC 2008 - Create an in-kernel API for "packet classes"

["anish babu" <anishbabu.m%gmail.com@localhost>]

On Fri, Apr 11, 2008 at 3:43 AM, Darren Reed <darrenr%netbsd.org@localhost> 
wrote:
>
> anish babu wrote:
>
> > >
> > >  Since you are working in this space, I'd like to see the packet-classes
> API
> > > be completely
> > >  independant of pf and pf tags - this may require more work from you to
> > > change pf but if
> > >  this isn't achieved, then you haven't really got a "packet class API",
> > > you've just moved
> > >  some of pf's code.
> > >
> > >  Further, to demonstrate that you've got the API correct, modify
> ipfilter to
> > > filter on these
> > >  packet classes and do this without referencing anything that is
> > > pf-specific.
> > >
> > >  Darren
> > >
> > >
> >
> > Darren,
> >
> > Yes You are right.But I have a doubt regarding implementation of this.
> >
> >  The main use of API is in 2 cases:
> >
> > 1) During the registration part of classes by ALTQ or driver : This
> > has nothing much to do with pf or pf_tags.
> >
> > 2)When PF calls this API to convert its tag name to token : I am not
> > sure how can I implement this mapping to find a corresponding token
> > for a tag which is pf specific.
> >
> > Did  I overlook something? Please let me know.
> >
> >
>
>  Maybe the key to finding the tag isn't just <tagname> but
> <tagname,consumer>,
>
>  Darren
>
>

I want to clarify one more thing on the project that I am working on -
'Create an in-kernal API for Packet Classes'. Instead of tagging the
packets by pf and then converting the tags to tokens, Is it not
possible to send the packets matching a particular rule set directly
to an output queue? I think it should work fine for queues created by
ALTQ but are there any issues with interface drivers?

Please let me know .

Thanks,
Anish