On Fri, Jun 2, 2017 at 2:17 AM, 爬山虎 <[email protected]> wrote: > > Thank you for you reply. > > Recently i have read the meter patch which realized in user mode space in > detail. Especially the "dp_netdev_run_meter" function. > > I don't think the implementation logical follow the openflow agreement. > > For example , command likes next: > > band=type=drop, rate=3000, burst_size= 4000 > band=type=drop, rate =5000, burst_size=6000 > > The implementation logical in that patch is choose the minimum speed limit > values , just always rate 3000 , and never have a chance to choose 5000. > Because the bucket of band just as for the rate in band basically. Is it > like this ? > > If follow with the openflow agreement, first we must have a measured speed. > This measured speed decide which band we to choose. In above example, if > measured speed is 4500, must choose rate 3000; if measured is 6500, must > choose rate 5000. >
The current meter test only configures a single band. Since you are suspecting there is a bug in supporting multiple band, it'd nice to see if the test can be expanded to illustrate the issue. Do you mind working on expanding the test and submitting a patch? If the test can demonstrate the problem, we will fix it. > We have too many questions about these . Even so , the next step our team > need to implement such an algorithm in kernel mode. If you hava any news > about meter, hope can tell us in advance. I am currently investigating adding meter support in the kernel module. Since OVS kernel module is part of the Linux kernel,, there is a constraint that the solution has to be acceptable by the kernel networking community. _______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
