[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: packet-classifier Summer of Code RFQ
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
> Most of the RFQ here is a re-phrasing of proposal outlined here:
> This is my understanding of the proposal, and may contain errors, in
> which case corrections are welcome.
> Request for Comment: packet-classifier API
> 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??
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
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.
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
Several programs purport to track this information, but none of them
have met my needs.
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.
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
David Young OJC Technologies
dyoung%ojctech.com@localhost Urbana, IL * (217) 278-3933
Main Index |
Thread Index |