On 09/20/14 at 06:19am, Jamal Hadi Salim wrote: > The ovs guys are against this and now no *api exists*? > Write a 15 tuple classifier tc classifier and use it. I will be more > than happy to help you. I will get to it when we have basics L2 working > on real devices.
Nothing speaks against having such a tc classifier. In fact, having the interface consist of only an embedded Netlink attribute structure would allow for such a classifier in a very straight forward way. That doesn't mean everybody should be forced to use the stateful tc interface. > Totally unacceptable in my books. If the OVS guys want some way out > to be able to ride on some vendor sdks then that is their problem. > We shouldnt allow for such loopholes. This is why/how TOE never made it > in the kernel. No need for false accusations here. Nobody ever mentioned vendor SDKs. The statement was that the requirement of deriving hardware flows from software flows *in the kernel* is not flexible enough for the future for reasons such as: 1) The OVS software data path might be based on eBPF in the future and it is unclear how we could derive hardware flows from that transparently. 2) Depending on hardware capabilities. Hardware flows might need to be assisted by software flow counterparts and it is believed that it is the wrong approach to push all the necessary context for the decision down into the kernel. This can be argued about and I don't feel strongly either way. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
