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

[David Young <dyoung%pobox.com@localhost>]

On Sat, Mar 29, 2008 at 05:01:53PM -0500, anish babu wrote:
> Proposed Approach:
> -----------------------------
> In order to solve this efficiently, I want to maintain a global table
> which maps class names identified by different traffic shapers and
> network interface drivers to a token name.
> 
> The tentative structure of the data structure is:( I understand that
> various extra fields need to be added to this table for efficient
> implementation)
> 
> +--------------------+---------------+
> | class_name   |   token_name  |
> +--------------------+---------------+
> |                      |               |
> +------------------------------------+
> |                      |               |
> +-----------------------------------+
> 
> So whenever a traffic shaper or Interface driver encounters a new
> class type, it registers that class name with this structure.
> 
> Then pf uses pf tag names to get corresponding token name and labels
> mbufs with that token name. ALTQ uses these tokens to select the
> corresponding scheduling class.

Your proposal is thin on details. :-) 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?

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

> Extending mbuf header is inefficient as for every mbuf of a packet (
> which can have multiple mbufs) we are allocating more kernal space
> unnecessarily. It suffices if we add an additional m_tag for each
> packet.

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?

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933 ext 24