The distribution version of OS of mime is CentOS Linux release 7.5.1804 (Core),and the kernel version is 3.10.0-862.14.4.el7.x86_64. I plan to merge the meters patch to the 3.10.0-862 kernel of CentOS7.5. Where is the function patch address? Do you have some suggestions?
Regards, yunxiang At 2019-01-29 02:49:59, "Justin Pettit" <jpet...@ovn.org> wrote: >I'd have to look at the history, but the feature wouldn't have been added to >OVN unless it was supported by OVS. Currently, we expect OVN to work with the >same version number of OVS. (Although, I expect you could use a newer version >of OVS and an older OVN.) We plan to break that requirement so that each OVS >and OVN can use different version going forward, but we're not there yet. > >--Justin > > >> On Jan 28, 2019, at 3:15 AM, taoyunupt <taoyun...@126.com> wrote: >> >> Hello,justin >> Forgive me! I have another question. As OVN use meters to >> implement QoS and meters was added from ovs2.10, how the ovn(<2.10) support >> QoS? >> >> >> >> Regards, >> Yunxiang >> >> >> At 2019-01-28 15:43:24, "Justin Pettit" <jpet...@ovn.org> wrote: >> >Sorry, I was thinking of another system that used OVS's tc instead of >> >meters to implement basic QoS. OVN does use meters to implement most modes >> >of QoS. If you don't want to use meters, you could try looking at the >> >"qos_max_rate" and "qos_burst" options in the ovn-nb man page, but I don't >> >have any experience using them. >> > >> >--Justin >> > >> > >> >> On Jan 27, 2019, at 11:26 PM, taoyunupt <taoyun...@126.com> wrote: >> >> >> >> The method build_qos in /ovn/northd/ovn-northd.c is as fellows,in the >> >> end of the method,it adds logical flow by the code of >> >> ovn_lflow_add(lflows, od, stage,qos->priority,qos->match, >> >> ds_cstr(&meter_action)); >> >> >> >> Does this mean the meter table is the only way for ovn to add Qos? >> >> >> >> >> >> >> >> build_qos(struct ovn_datapath *od, struct hmap *lflows) { >> >> ovn_lflow_add(lflows, od, S_SWITCH_IN_QOS_MARK, 0, "1", "next;"); >> >> ovn_lflow_add(lflows, od, S_SWITCH_OUT_QOS_MARK, 0, "1", "next;"); >> >> ovn_lflow_add(lflows, od, S_SWITCH_IN_QOS_METER, 0, "1", "next;"); >> >> ovn_lflow_add(lflows, od, S_SWITCH_OUT_QOS_METER, 0, "1", "next;"); >> >> >> >> for (size_t i = 0; i < od->nbs->n_qos_rules; i++) { >> >> struct nbrec_qos *qos = od->nbs->qos_rules[i]; >> >> bool ingress = !strcmp(qos->direction, "from-lport") ? true >> >> :false; >> >> enum ovn_stage stage = ingress ? S_SWITCH_IN_QOS_MARK : >> >> S_SWITCH_OUT_QOS_MARK; >> >> int64_t rate = 0; >> >> int64_t burst = 0; >> >> >> >> for (size_t j = 0; j < qos->n_action; j++) { >> >> if (!strcmp(qos->key_action[j], "dscp")) { >> >> struct ds dscp_action = DS_EMPTY_INITIALIZER; >> >> >> >> ds_put_format(&dscp_action, "ip.dscp = %"PRId64"; next;", >> >> qos->value_action[j]); >> >> ovn_lflow_add(lflows, od, stage, >> >> qos->priority, >> >> qos->match, ds_cstr(&dscp_action)); >> >> ds_destroy(&dscp_action); >> >> } >> >> } >> >> >> >> for (size_t n = 0; n < qos->n_bandwidth; n++) { >> >> if (!strcmp(qos->key_bandwidth[n], "rate")) { >> >> rate = qos->value_bandwidth[n]; >> >> } else if (!strcmp(qos->key_bandwidth[n], "burst")) { >> >> burst = qos->value_bandwidth[n]; >> >> } >> >> } >> >> if (rate) { >> >> struct ds meter_action = DS_EMPTY_INITIALIZER; >> >> stage = ingress ? S_SWITCH_IN_QOS_METER : >> >> S_SWITCH_OUT_QOS_METER; >> >> if (burst) { >> >> ds_put_format(&meter_action, >> >> "set_meter(%"PRId64", %"PRId64"); next;", >> >> rate, burst); >> >> } else { >> >> ds_put_format(&meter_action, >> >> "set_meter(%"PRId64"); next;", >> >> rate); >> >> } >> >> >> >> /* Ingress and Egress QoS Meter Table. >> >> * >> >> * We limit the bandwidth of this flow by adding a meter >> >> table. >> >> */ >> >> ovn_lflow_add(lflows, od, stage, >> >> qos->priority, >> >> qos->match, ds_cstr(&meter_action)); >> >> ds_destroy(&meter_action); >> >> } >> >> } >> >> } >> >> >> >> >> >> >> >> >> >> >> >> At 2019-01-28 15:15:51, "Justin Pettit" <jpet...@ovn.org> wrote: >> >> >QoS is most likely using the kernel's built-in traffic-shaping >> >> >algorithms in tc. Those should work the same on all supported kernels. >> >> > >> >> >--Justin >> >> > >> >> > >> >> >> On Jan 27, 2019, at 11:10 PM, taoyunupt <taoyun...@126.com> wrote: >> >> >> >> >> >> >> >> >> Thanks justin, >> >> >> >> >> >> My environment is OVS for the OVN/openstack.I also want to know ,if i >> >> >> must use meter for the openstack/ovn feature 'Qos'.Does any other >> >> >> methods to achive this? >> >> >> >> >> >> Regards, >> >> >> Yunxiang >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> At 2019-01-28 14:58:19, "Justin Pettit" <jpet...@ovn.org> wrote: >> >> >> >This is the patch: >> >> >> > >> >> >> > http://patchwork.ozlabs.org/patch/950513/ >> >> >> > >> >> >> >I think it was only broken in kernels 4.15, 4.16, and 4.17. I expect >> >> >> >that 4.20 will be fine. >> >> >> > >> >> >> >--Justin >> >> >> > >> >> >> > >> >> >> >> On Jan 27, 2019, at 10:16 PM, taoyunupt <taoyun...@126.com> wrote: >> >> >> >> >> >> >> >> Hello,justin, >> >> >> >> I met a supporting problem of meter of OVS 2.10. I found >> >> >> >> a mail from you,after searching the internet.The address of this >> >> >> >> mail is >> >> >> >> "https://www.mail-archive.com/ovs-discuss@openvswitch.org/msg04180.html" >> >> >> >> The kernel version of "4.20.5-1.el7.elrepo.x86_64" goes >> >> >> >> well with meter table of ovs,but I want to know how to fit the >> >> >> >> maintained older kernels. >> >> >> >> If i want to use ovs with maintained older kernels,which >> >> >> >> patch you metioned in the mail, should i import ? >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Regards, >> >> >> >> yunxiang >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> >> discuss mailing list >> >> >> >> disc...@openvswitch.org >> >> >> >> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss >> >> >> >> >> >>
_______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss