tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: GSOC - 2008 - "create an in-kernal API for packet classes" project discussion

Anish wrote:
Goal:  An API which enables

 1) Drivers to register which classes of packets they identify
 2) PF labels each packet with a token specifying packet class they
registered above ( It can't use pf tags as they are not recognized
outisde pf)
 3) ALTQ uses these tokens to direct them to appropriate queue.

I have some more questions regarding this . Please reply me :

1) How is sending of packets to a particular queue handled currently ?
( Is that funtionality there  or not? ALTQ can recognize pf tags
right? So, ALTQ should be doing this and not drivers? )

2) All of this scenario makes sense only for outgoing packets. Is
there any case of incoming packets to be considered as part of this?

The last question makes me wonder if more serious changes are
needed within NetBSD networking to understand different packet
classes going both down to the NIC and up from the NIC.


Today the more advanced NICs have on-board classification and
multiple descriptor rings - both features that NetBSD currently
is unable to use. One method of interaction here would be for
drivers - or a layer above drivers - to tag packets with their
class as a result of said on-board classification.  But if you're
doing that then it may make a certain amount of sense to emulate
such hardware features in software so that dumb NICs can be made
to look like smart ones and the classification easier.

But that's a whole lot of work that is beyond the scope of what
you're doing.

One thing to keep in mind, with your project, is how would the API
be used or expanded upon if there are multiple transmit rings.  This
is probably more of something for ALTQ to deal with and should be
hidden from what's above.

At some point we (NetBSD) need to think about whether or not there
should be a real layer of stuff between device drivers and IP so
that things like ALTQ can plugin to that and to which APIs such as
the one you'll be developing could belong to.


Home | Main Index | Thread Index | Old Index