[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: packet-classifier Summer of Code RFQ
On Fri, Mar 26, 2010 at 04:07:25PM -0400, Andy Pyles wrote:
> On Thu, Mar 25, 2010 at 7:43 PM, David Young <dyoung%pobox.com@localhost>
> > On Thu, Mar 25, 2010 at 10:16:22AM -0400, Andy Pyles wrote:
> > 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
> 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.
Just for example, an Atheros WLAN NIC supports more than one type of
service, and a Realtek WLAN NIC provides three transmission rings.
IIRC, ath(4) supports 802.11 type of service (WME), but that's not
It seems that you need to expand on your API in order to support both
packet classifications and types of service.
What do you think?
> > 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)
That only shows flow information for current filter states---i.e., no
past information. The information is not easily digested by a person or
by a visualization program.
> > 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?
Today, you can control the maximum length of the queue with a sysctl,
only, and that's a recent development!
> > 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.
It's an issue even on 100 Mb/s cards if they've negotiated a slow link
rate (10 Mb/s).
> The overhead of prioritizing packets in the transmit ring could
> impede performance though.
Why do you say that?
David Young OJC Technologies
dyoung%ojctech.com@localhost Urbana, IL * (217) 278-3933
Main Index |
Thread Index |