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
