On Wed, Feb 15, 2017 at 01:48:37PM +0200, Roi Dayan wrote: > On 15/02/2017 13:16, Chandran, Sugesh wrote: > >>From: Roi Dayan [mailto:r...@mellanox.com] ... > >>On 14/02/2017 01:53, Chandran, Sugesh wrote: > >>>>From: Roi Dayan [mailto:r...@mellanox.com] ... > >>>>+ tc_set_policy(smap_get_def(ovs_other_config, "tc-policy", > >>>>+ TC_POLICY_DEFAULT)); > >>>>+ > >>>[Sugesh] I feel we better call this policy as hw-ofld-policy than > >>>tc-policy. As > >>far as I know tc is one of the way to program the hardware. In the dpdk dpif > >>there must be be another flow programming interface that can be used to > >>program the offload. It would be nice if we can use the same configuration > >>option for all the deployments. > >> > >>currently the options used in tc-policy are somewhat tc specific. > >>the options could be a lot different for other interfaces. > >>maybe leave this like this for now? > >>if another interface will have a policy then we can revisit this if the same > >>options apply or if we can merge those options or maybe we'll see we'll need > >>an entirely different [interface]-policy option? > >[Sugesh] Ok, I am fine with leaving it . But out of curiosity, just > >wondering what would be other possible policy options you are expecting for > >other type of interfaces?? I assume the policy is more or less the way > >hardware get programmed. It has nothing to do with what approach used to > >program it, which can be tc or any other APIs. > > > > > > I'm not sure. for example tc use negative approach (skip_sw/skip_hw) and if > you leave it empty it's "both". > Other interface could use a positive approach like offload_hw, offload_sw, > offload_both.. > Though it very well could be it would just be hw-offload-policy later..
I think another consideration when naming options is that policy could be implemented in different places. In the case of the option above it affects policy implemented by the kernel regarding where it places a flow in the context of TC with the flower classifier: not in sw, not in hw, or an implementation-defined default. The last option is, as far as I understand: * Add to sw and; * Add to hw if an offload callback is provided by the driver But there is also a policy present in OvS, currently in the DPIF code in this patchset, which is as follows: * Try to add flow using offload callback * If that fails - e.g. due to the callback not being present then - Try to add flow to OvS datapath In a sense the above is already configurable by the "hw-offload" option provided by this patchset which allows skipping trying to add the flow using the offload callback. However, there are other possibilities for the policy implemented in the DPIF code. In particular I would like to see the following supported: * Try to add flow using offload callback * Regardless of if that fails or not - Try to add flow to OvS datapath We can debate the merit of the last policy above but my point is not that specific policy but rather that policy exists in two places - the kernel and the DPIF - and that both could plausibly be called "hw-ofld-policy". ... _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
