Thomas Graf wrote:
* Andy Furniss <[EMAIL PROTECTED]> 2005-01-11 15:28

diff -urN linux-2.6.10.orig/include/linux/pkt_sched.h 
linux-2.6.10/include/linux/pkt_sched.h
@@ -136,6 +143,7 @@
        __u32           limit;          /* Maximal packets in queue */
        unsigned        divisor;        /* Hash divisor  */
        unsigned        flows;          /* Maximal number of flows  */
+       unsigned        hash_kind;      /* Hash function to use for flow 
identification */
};


This breaks compatibility to older iproute2 versions
compiled with older header versions (not including
the additional 4 octets). sch_sfq.c:

        if (opt->rta_len < RTA_LENGTH(sizeof(*ctl)))
                        return -EINVAL;

I did wonder if it could just come out now that iproute2 uses its own pkt_sched.h.


Just to be sure I understand - it's a risk that always existed eg. before Stephen maintained iproute2, when it compiled against kernel headers. If I patched kernel and failed to compile new tc/had old tc ahead in path etc. then sfq would be broken.

So if you patch make sure you build and use new tc do tc -V / check you don't have an old one in /sbin as iproute2's make install uses /usr/sbin by default.



+static int esfq_change(struct Qdisc *sch, struct rtattr *opt)
+{
+       struct esfq_sched_data *q = qdisc_priv(sch);
+       struct tc_sfq_qopt *ctl = RTA_DATA(opt);
+       int old_perturb = q->perturb_period;
+
+       if (opt->rta_len < RTA_LENGTH(sizeof(*ctl)))
+               return -EINVAL;
+
+       sch_tree_lock(sch);
+       q->quantum = ctl->quantum ? : psched_mtu(sch->dev);
+       q->perturb_period = ctl->perturb_period*HZ;
+//     q->hash_divisor = ctl->divisor;
+//     q->tail = q->limit = q->depth = ctl->flows;
+
+       if (ctl->limit)
+               q->limit = min_t(u32, ctl->limit, q->depth);
+       
+       if (ctl->hash_kind) {
+               q->hash_kind = ctl->hash_kind;
+               if (q->hash_kind !=  TCA_SFQ_HASH_CLASSIC)
+                       q->perturb_period = 0;
+       }
+       
+       // is sch_tree_lock enough to do this ?
+       while (sch->q.qlen >= q->limit-1)
+               esfq_drop(sch);
+       
+       if (old_perturb)
+               del_timer(&q->perturb_timer);
+       if (q->perturb_period) {
+               q->perturb_timer.expires = jiffies + q->perturb_period;
+               add_timer(&q->perturb_timer);
+       } else {
+               q->perturbation = 0;
+       }
+       sch_tree_unlock(sch);
+       return 0;
+}


Must be changed to use tcf_exts and ematch api once those patches
are merged. I will take care of this.

I'll have a closer look later on this week.


Thanks.

Andy.

_______________________________________________
LARTC mailing list / [email protected]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Reply via email to