Re: packet-classifier Summer of Code RFQ

[David Young <dyoung%pobox.com@localhost>]

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

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

Dave

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