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

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

Hi,

My name is Anish and I am a graduate student at Texas A&M University.
I want to work on the project 'Create an in-kernel API for "packet
classes"' . I made a detailed proposal for this project:

Problem Description:
------------------------------

Create an in-kernel API for registering "packet classes" and for
labeling packets with their class, for special treatment by traffic
shapers (ALTQ) and by network interface drivers. With the registration
part of the API, ALTQ or a driver registers the names of packet
classes it recognizes. For example, ALTQ will register the
'class_name' part of a Class Command . An Ethernet NIC with high- and
low-priority transmit rings may register classes called 'hipri' and
'lopri'. An 802.11 NIC may register 802.11e traffic categories, BE,
BK, VI, VO. Each registration yields a token that is suitable for
labeling a packet - i.e., a small amount of data to stick in an mbuf
packet header or in an m_tag.

Make PF use the packet-classes API to convert PF tag names—see
pf.conf(5) for more about tags—to packet-class tokens, and to label
mbufs with the tokens as they exit PF. Make ALTQ extract the
packet-class tokens from mbufs and use them to select the
packet-scheduling class.

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.

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.

---->If I am more abstract about any implementation details please let
me know.  Even If I am missing something in this proposal, please feel
free to ask.

Thanks,
Anish