Sat, Sep 20, 2014 at 01:32:30PM CEST, j...@mojatatu.com wrote: >On 09/20/14 07:01, Thomas Graf wrote: > >>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. >> > > >Agreed. The response was to Jiri's strange statement that now that >he cant use OVS, there is no such api. I point to tc as very capable of >such usage.
Jamal, would you please give us some examples on how to use tc to work with flows? I have a feeling that you see something other people does not. Lets get on the same page now. Thanks. > >>No need for false accusations here. Nobody ever mentioned vendor SDKs. >> > >I am sorry to have tied the two together. Maybe not OVS but the approach >described is heaven for 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. >> > >Who says you cant put BPF in hardware? >And why is OVS defining how BPF should evolve or how it should be used? > >>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. >> > >Pointing to the current FDB offload: You can select to bypass >and not use s/ware. > >cheers, >jamal _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
