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. 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