Le vendredi 25 novembre 2011 à 06:34 -0500, jamal a écrit : > Hrm. I forgot about the flow classifier - it may be what the openflow > folks need. It is more friendly for the well defined tuples than u32. > > But what do you mean "refactor"? I can already use this classifier > and attach actions to set policy in the kernel.
cls_flow is not complete, since it doesnt handle tunnels for example. It calls a 'partial flow classifier' to find each needed element, one by one. (adding tunnel decap would need to perform this several time for each packet) __skb_get_rxhash() is more tunnel aware, yet some protocols are still missing, for example IPPROTO_IPV6. Instead of adding logic to both dissectors, we could have a central flow dissector, filling a temporary pivot structure with found elements (src addr, dst addr, ports, ...), going through tunnels encap if found. Then net/sched/cls_flow.c could pick needed elems from this structure to compute the hash as specified in tc command : (for example : tc filter ... flow hash keys proto-dst,dst ...) (One dissector call per packet for any number of keys in the filter) Same for net/sched/sch_sfb.c : Use the pivot structure and compute the two hashes (using two hashrnd values) And __skb_get_rxhash() could use the same flow dissector, and pick (src addr, dst addr, ports) to compute skb->rxhash, and set skb->l4_rxhash if "ports" is not null. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
