tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: packet-classifier Summer of Code RFQ



On Fri, Apr 02, 2010 at 11:43:30PM +0300, Mihai Chelaru wrote:
> Andy Pyles wrote:
> 
> > ---------
> > In kernel API for registering packet classes
> > --------
> 
> Hi Andy,
> 
> The main issue is how to map between classes registered by different
> interfaces. Think that you have two interfaces, one (let's call it input)
> have M priority classes and other (let's call it output) has N priority
> classes and you have to forward packets from input to output, keeping in
> mind that higher priority should be put on wire first, no matter what. For
> example think that pf is registering 4 classes (realtime, high, medium,
> low) and you have to map those on 2 hi-lo ethernet rings. In order to
> achieve this you have to design solutions (and finally code common
> interfaces) for at least these issues:
> 
> - how can you parse queues (and rings in ethernet case) in order to see what
> packets/frames are there ?
> - how can you insert priority packets into queues ?
> - what should you do if queues are full and you need to insert a high
> priority packet ?
> - how can you flush packets from rings and refeed them to driver queue ?
> 
> Also pseudo-interfaces like gre should have a mechanism in order to
> automatically map to "parent" interface. Keep in mind that a
> pseudo-interface can have a different number of classes than its parent.

There can be no fixed relationship between pseudo-interfaces and "real"
interfaces.

Perhaps every interface, pseudo- or not, should apply a mapping from
packet class to packet class in its output routine?  Maybe we can come
up with a good conceptual model and, eventually, an architecture, by
thinking of per-interface class-to-class mappings.

Where C is the set of packet classes, and I is the set of interfaces,
let there be a global class map, g : I x C -> C, and a mapping for each
interface, f[i] : C -> C, f[i](c) = g(i, c).  Let c[d] be the default
packet class.

A reasonable global default mapping is g(i, c) = c[d].

Sometimes, for a tunnel 't', the identity mapping may be appropriate:

        f[t](c) -> c

For a WLAN, w, net80211 currently provides this default mapping from IP
ToS field to WME classes, in ieee80211_classify():

        f[w](tos) -> BK ("background") if tos is in {0x08, 0x20}
                     VI ("video") if tos is in {0x28, 0xa0}
                     VO ("voice") if tos is in {0x30, 0xe0, 0x88, 0xb8}
                     BE ("best effort") for all other tos

> Moreover, think that other kernel interfaces like INET can register
> classes.

Good point.

> In this case an interface should be presented to userspace - probably via
> setsockopt (if we're thinking only about pre-defined classes).

Already there is a socket option for IP ToS. ip(4) gives this example:

     setsockopt(s, IPPROTO_IP, IP_TOS, &tos, sizeof(tos));

Supposing that there is a global packet-class namespace, we need just
one new socket-level option:

     setsockopt(s, SOL_SOCKET, SO_PKT_CLASS, &pkt_class, sizeof(pkt_class));

Dave

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


Home | Main Index | Thread Index | Old Index