[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netbsd-tech-net
Subject:    Re: GSoC 2008 - Create an in-kernel API for "packet classes"
From:       "anish babu" <anishbabu.m () gmail ! com>
Date:       2008-03-30 17:10:46
Message-ID: 1a31da330803301010t209283e1se35715765bd949fe () mail ! gmail ! com
[Download RAW message or body]

> What data type will you use for
>  the tokens?  How do PF, ALTQ, and drivers add tokens to the system?
>  When do you resolve class names to tokens?


I think unsigned long int can be used for tokens. Each of them
maintains a local table which stores the classes found so far and if a
new class is encountered , they call an API which registers the class
name and returns the corresponding token name. This token name can be
stored in local table for further access.

>
>  What will you do if the kernel starts to label an mbuf with its class,
>  and that mbuf is already labelled?
>


If mbuf is used,a flag can be maintained  in header, or for m_tags, we
can search for the corresponding tag type and then confirm. Right?
I am sorry if any of my answers look trivial as I have not completely
started working with code.


>
>  How much more kernel space would you need to add to an mbuf?  It seems
>  to me that there are trade-offs whether you enlarge the mbuf structure
>  or use an m_tag.  What do you think?
>

On Sat, Mar 29, 2008 at 8:16 PM, Joerg Sonnenberger
<joerg@britannica.bec.de> wrote:
>
>  Having done exact the embedding of basic FW state and ALTQ options into
>  the pkthdr on DragonFly -- it is much simpler and faster, the only
>  difference is that it has to switch to clusters a bit earlier. That is
>  not a big deal if you ensure that you have at least 80 byte or so in the
>  first mbuf free (mbuf size - pkthdr size).
>

As suggested by Joerg, going for mbuf seems to be a better option to
me now. What you say?

Thanks for your valuable suggestions David and thank you Joerg
Anish
[prev in list] [next in list] [prev in thread] [next in thread]