Re: packet-classifier Summer of Code RFQ

[Andy Pyles <ajpyles%cs.wm.edu@localhost>]

Comments inline:

On Thu, Mar 25, 2010 at 7:43 PM, David Young <dyoung%pobox.com@localhost> wrote:
> On Thu, Mar 25, 2010 at 10:16:22AM -0400, Andy Pyles wrote:
>> ---------
>> In kernel API for registering packet classes
>> --------
>>
>>
>> Hello, I'm interested in the Summer of Code proposal for
>> packet-classifier API. Below is a proposal that I have put together
>> regarding this SOC project. Any comments provided will be greatly
>> appreciated.
>> Most of the RFQ here is a re-phrasing of proposal outlined here:
>> http://www.netbsd.org/contrib/soc-projects.html#packet-classifying
>> This is my understanding of the proposal, and may contain errors, in
>> which case corrections are welcome.
>>
>>
>> Request for Comment: packet-classifier API
>>
>> Overview:
>> Currently when a new class is added via pf/ALTQ / ALTQD it is added to
>> an internal ALTQ data structure. Similarly, PF uses tags, it's own
>> data structure for tagging packets.  Since PF and ALTQ are tightly
>> coupled together, I propose a way to decouple PF and ALTQ.  For
>> instance, suppose an alternative firewall would like to integrate with
>> ALTQ? Currently there is not a viable way to accomplish this outside
>> of the tight coupling that is done with PF. What is required is a
>> common API that can be used by ALTQ, PF and network device drivers.
>>     This common API is coined the "packet-classifier" API. The
>> packet-classifier will store packet classes in a separate data
>> structure. ALTQ and network device drivers can register new classes
>> with the packet-classifier. An ethernet device driver could register
>> two classes "hi_priority" and "low_priority" with the
>> packet-classifier for instance if it contains transmit rings of
>> different priority. When a register() is successful, the
>> packet-classifier returns a token than can then be used for labeling a
>> packet placed in an MBUF for instance that can be classified later.
>>
>> The packet-classifier API will have the following function calls:
>>      Token *packet_classifier_register(....); // register a new class
>> returns Token
>>      int packet_classifier_lookup(....);  // lookup classifier
>>      int packet_classifier_destroy(Token); // destroy classifier with
>> associated Token
>>      int packet_classifier_replace(Token,.....); // replace classifier
>> with associated Token, with updated         information.
>>      TODO:  others??
>
> Andy,
>
> A couple of comments about your proposal:
>
> 1) Some of the ALTQ schedule types *may* be able to use a "packet
>   extract," such as a src/dst port/addr tuple (or hash), that the
>   packet filter has already calculated.  For example, a schedule may
>   assign packets to different queues using the hash of the source port
>   & address.

OK. This is good to know, this could help in performance.

>
> 2) Each interface may need a mapping from one or more class-labels
>   applied by the packet filter to service categories.  E.g., "bulk"
>   may be the name of a packet classification, but "hipri" and "lopri"
>   are NIC 1's service types, and "hi", "med", "lo" are NIC 2's service
>   types.  The operator may desire for NIC 1 to assign service type
>   "lopri" to "bulk" packets, and for NIC 2 to assign service type "med"
>   to "bulk" packets.

So there should be a distinction between service types and
class-labels then. Perhaps when registering to the packet-classifier
API,
we should distinguish if this is a generic class-label to a service
category. Can you give an example of a NIC with these characteristics?
Also is that even possible to configure different service types on a
NIC? A quick scan through some of the latest device driver man pages
did not indicate how this is done.


>
> BTW, these days I am also concerned with three problems that are
> related to the packet-classifying one:
>
> 1) What flows go through my router or network interface, *right now*?
>   How much traffic is in each flow?  What are the historical flows on
>   this router/interface?
>
>   Several programs purport to track this information, but none of them
>   have met my needs.

Doesn't pfctl -sa give you all that you need? What is it that you are
not getting from this output?( Assuming you are using PF)

>
> 2) Lots of bus-mastering NICs have both a transmit-descriptor ring that
>   holds umpteen packets, and a transmission queue (struct ifnet member
>   if_snd) that holds umpteen more.  The queue empties into the ring.
>   The queue size is controllable by sysctl, but the ring size usually
>   is not.  ISTM that *one* sysctl variable should control the maximum
>   length of the ring plus the queue.
>
What is the current behavior?

>   A related problem is that ALTQ operates on the transmission queue,
>   not on the ring+queue.  I don't think that ALTQ can be effective by
>   prioritizing packets on the transmission queue if the ring can grow
>   very long.

I see how this could be an issue. How large can the ring get? I
imagine on some of the gigabit cards this could be more of an issue
because there is probably a larger transmit ring on these.
The overhead of prioritizing packets in the transmit ring could
impede performance though.

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

Dave,