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

[Anish]

Hi,

My name is Anish. I am glad to say that I was selected to work on the
project " Create an in-kernal API for packet classes" as part of
Google Summer of Code - 2008. My Mentor is Herb Peyerl and I am glad
too that my mentor is very passionate and is giving me great guidance.
Earlier I discussed some details of the project on this mailing list.
It is briefly as follows:

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?

Thanks,
Anish

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

Post by Anish
...
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.
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.

Why?

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.

Darren


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de