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.
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
