Re: [ovs-dev] [PATCH v2] ofproto-dpif-upcall: Improve concurrency by adjust flow-limit
Hi ，
Please help to review this patch. It has passed couple of days. Hope to
know your idea. Thanks.
Thanks,
YUN
At 2021-05-26 10:44:16, "Tao YunXiang" wrote:
>OVS uses a set of gentle mechanisms to control the number of flows in
>datapath. However, it is difficult for the number of datapath flows to
>reach a high level in a short time.
>
>Through some tests with Apache benchmark, I found the point is that
>the value of flow-limit increases too slowly, but decreases very quickly.
>
>This change has two improvements. One is the flow-limit will adjust more
>linearly. The other one is, when the duration is small, the flow-limit will
>increase faster.
>
>Through this change, the test result of Apache benchmark can reach 12k from 5k,
>the test command is as follows:
>
>ab -n 20 -c 500 -r http://1.1.1.2/
>
>v1->v2: Make flow-limit changes linearly. Add a limitation to make flow_limit
>won't overflow UINT_MAX.
>
>
>Signed-off-by: Tao YunXiang
>Cc: Ben Pfaff
>
>---
> ofproto/ofproto-dpif-upcall.c | 20 +---
> 1 file changed, 13 insertions(+), 7 deletions(-)
>
>diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c
>index ccf97266c..805409165 100644
>--- a/ofproto/ofproto-dpif-upcall.c
>+++ b/ofproto/ofproto-dpif-upcall.c
>@@ -963,14 +963,20 @@ udpif_revalidator(void *arg)
>
> duration = MAX(time_msec() - start_time, 1);
> udpif->dump_duration = duration;
>-if (duration > 2000) {
>-flow_limit /= duration / 1000;
>-} else if (duration > 1300) {
>-flow_limit = flow_limit * 3 / 4;
>-} else if (duration < 1000 &&
>- flow_limit < n_flows * 1000 / duration) {
>-flow_limit += 1000;
>+
>+/* Use duration as a reference, adjust the value of flow_limit,
>+ * when the duration is short, increase the flow_limit, and vice
>+ * versa. The purpose of using multiple conversions between int
>+ * and float is to make the flow_limit change more linear. */
>+
>+if (duration >= 1000) {
>+flow_limit = (int) ((float) (flow_limit) / (duration /
>1000.0));
>+} else if (flow_limit * (1000.0 / duration) >= UINT_MAX) {
>+flow_limit = ofproto_flow_limit;
>+} else {
>+flow_limit = (int) (flow_limit * (1000.0 / duration));
> }
>+
> flow_limit = MIN(ofproto_flow_limit, MAX(flow_limit, 1000));
> atomic_store_relaxed(>flow_limit, flow_limit);
>
>--
>2.17.1
>
>
>
>___
>dev mailing list
>d...@openvswitch.org
>https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] system-traffic.at:add missing comma
Hi ， Please help to review this patch. It has passed couple of days. Thanks. Thanks, YUN At 2021-05-26 10:53:45, "Tao YunXiang" wrote: >Add missing comma. > >Signed-off-by: Tao YunXiang >Cc: Joe Stringer > >--- > tests/system-traffic.at | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/tests/system-traffic.at b/tests/system-traffic.at >index fb5b9a36d..ed925cea5 100644 >--- a/tests/system-traffic.at >+++ b/tests/system-traffic.at >@@ -2561,7 +2561,7 @@ priority=10,arp,action=normal > > dnl Only allow non-fragmented messages and 1st fragments of each message > priority=100,in_port=1,icmp,ip_frag=no,action=ct(commit,zone=9),2 >-priority=100,in_port=1,icmp,ip_frag=firstaction=ct(commit,zone=9),2 >+priority=100,in_port=1,icmp,ip_frag=first,action=ct(commit,zone=9),2 > priority=100,in_port=2,ct_state=-trk,icmp,action=ct(table=0,zone=9) > priority=100,in_port=2,ct_state=+trk+est-new,icmp,action=1 > ]) >-- >2.17.1 > > > >___ >dev mailing list >d...@openvswitch.org >https://mail.openvswitch.org/mailman/listinfo/ovs-dev ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2] Improve concurrency by adjust flow-limit
Hi Ben,
Please help to review this patch ,which to optimize the flow-limit
adjustment.
The v1 patch links to
http://patchwork.ozlabs.org/project/openvswitch/patch/20210511075200.19037-1-taoyunxi...@cmss.chinamobile.com/
Thanks,
Yun
At 2021-05-17 15:22:48, "Tao YunXiang" wrote:
>OVS uses a set of gentle mechanisms to control the number of flows in
>datapath. However, it is difficult for the number of datapath flows to
>reach a high level in a short time.
>
>Through some tests with Apache benchmark, I found the point is that
>the value of flow-limit increases too slowly, but decreases very quickly.
>
>This change has two improvements. One is the flow-limit will adjust more
>linearly. The other one is, when the duration is small, the flow-limit will
>increase faster.
>
>Through this change, the test result of Apache benchmark can reach 12k from 5k,
>the test command is as follows:
>
>ab -n 20 -c 500 -r http://1.1.1.2/
>
>v1->v2: Make flow-limit changes linearly. Add a limitation to make flow_limit
>won't overflow UINT_MAX.
>
>
>Signed-off-by: Tao YunXiang
>Cc: Ben Pfaff
>
>---
> ofproto/ofproto-dpif-upcall.c | 20 +---
> 1 file changed, 13 insertions(+), 7 deletions(-)
>
>diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c
>index ccf97266c..805409165 100644
>--- a/ofproto/ofproto-dpif-upcall.c
>+++ b/ofproto/ofproto-dpif-upcall.c
>@@ -963,14 +963,20 @@ udpif_revalidator(void *arg)
>
> duration = MAX(time_msec() - start_time, 1);
> udpif->dump_duration = duration;
>-if (duration > 2000) {
>-flow_limit /= duration / 1000;
>-} else if (duration > 1300) {
>-flow_limit = flow_limit * 3 / 4;
>-} else if (duration < 1000 &&
>- flow_limit < n_flows * 1000 / duration) {
>-flow_limit += 1000;
>+
>+/* Use duration as a reference, adjust the value of flow_limit,
>+ * when the duration is short, increase the flow_limit, and vice
>+ * versa. The purpose of using multiple conversions between int
>+ * and float is to make the flow_limit change more linear. */
>+
>+if (duration >= 1000) {
>+flow_limit = (int) ((float) (flow_limit) / (duration /
>1000.0));
>+} else if (flow_limit * (1000.0 / duration) >= UINT_MAX) {
>+flow_limit = ofproto_flow_limit;
>+} else {
>+flow_limit = (int) (flow_limit * (1000.0 / duration));
> }
>+
> flow_limit = MIN(ofproto_flow_limit, MAX(flow_limit, 1000));
> atomic_store_relaxed(>flow_limit, flow_limit);
>
>--
>2.17.1
>
>
>
>___
>dev mailing list
>d...@openvswitch.org
>https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ofproto-dpif-upcall: Improve concurrency by adjust flow-limit
At 2021-05-13 01:20:29, "Ben Pfaff" wrote:
>On Wed, May 12, 2021 at 10:44:12AM +0800, taoyunupt wrote:
>> At 2021-05-12 04:00:30, "Ben Pfaff" wrote:
>> >On Tue, May 11, 2021 at 03:52:00PM +0800, Tao YunXiang wrote:
>> >> +/* Use duration as a reference, adjust the number of
>> >> flow_limit,
>> >> + * when the duration is small, increase the flow-limit, and
>> >> vice versa */
>> >> +if (duration >= 1000) {
>> >> flow_limit /= duration / 1000;
>> >> -} else if (duration > 1300) {
>> >> -flow_limit = flow_limit * 3 / 4;
>> >> -} else if (duration < 1000 &&
>> >> - flow_limit < n_flows * 1000 / duration) {
>> >> -flow_limit += 1000;
>> >> +} else {
>> >> +flow_limit *= 1000 / duration;
>> >> }
>> >> flow_limit = MIN(ofproto_flow_limit, MAX(flow_limit, 1000));
>> >> atomic_store_relaxed(>flow_limit, flow_limit);
>> >
>> >The above is very abrupt. It always tries to adjust the flow limit
>> >upward or downward. I think that this is a bad idea, especially in the
>> >upward direction. If there are only a few flows, which only take a few
>> >milliseconds to revalidate, then it will keep increasing the flow limit
>> >upward until it overflows the range of unsigned int. It will happen
>> >very quickly, in fact: if duration is 1 ms three times in a row, then we
>> >will multiply flow_limit by 1,000,000,000 and overflow 32-bit UINT_MAX;
>> >if it happens six times in a row, we will overflow 64-bit.
>>
>> >
>> Hi,Ben,
>> Thanks for your review.
>> It won't overflow, because of the following line of
>> code(https://github.com/openvswitch/ovs/blob/master/ofproto/ofproto-dpif-upcall.c#L974),which
>> makes it won't over `ofproto_flow_limit` .
>> For example, if currently flow-limit is 200,000(the default
>> ofproto_flow_limit), and duration is 1ms, it will become 200,000,000 ,which
>> is much less than 32-bit UINT_MAX(4,294,967,295).
>> And then, it wil be back to 200,000,because of the limtitaion mentioned
>> above, I think this is important.
>
>OK. Is there anything that ensures that ofproto_flow_limit is no more
>than UINT_MAX/1000? Otherwise we still have the problem, if
>ofproto_flow_limit is set high.
I sent v2 to add a limitation to avoid this.
>> >Furthermore, it doesn't work well even if we have longer durations. If
>> >revalidation takes 501 ms, then we can adjust the flow_limit upward, but
>> >this won't do it.
>>
>>
>> emm...though，it won't change when `501ms`， but it will change when `500ms`
>> or times of 2 or 5 .
>> If you think it's needed to make process more linear, we can change its
>> type from int to float.
>> what do you think?
>
>I think that more linear makes more sense. Always adjusting by a factor
>of 2 will probably cause oscillation.
I sent v2 to make adjustment more linear.
>
>> >On the downward direction, this new code does nothing if the duration is
>> >less than 2 seconds. We want to aim for 1-second revalidation times.
>>
>> >
>>
>>
>> In this code ,I changed the benchmark value from 2s and 1.3s to 1s. It aims
>> for 1-second revalidation times.
>> Do I misunderstand your point? please let me know , thanks. The following
>> is the new code.
>>
>>
>> if (duration >= 1000) {
>> flow_limit /= duration / 1000;
>> } else {
>> flow_limit *= 1000 / duration;
>> }
>> flow_limit = MIN(ofproto_flow_limit, MAX(flow_limit, 1000));
>
>This will do nothing if the duration is between 501 ms and 1999 ms, and
>if it's outside that range then it will always adjust by a factor of 2
>or more. I think that is too wide a range and I think that the minimum
>adjustment factor is too high.
I sent v2 to make adjustment more linear , I think it will avoid this situtaion
you mentioned.
Thanks,
YUN
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ofproto-dpif-upcall: Improve concurrency by adjust flow-limit
At 2021-05-12 04:00:30, "Ben Pfaff" wrote:
>On Tue, May 11, 2021 at 03:52:00PM +0800, Tao YunXiang wrote:
>> Author: Tao YunXiang
>
>You don't need an Author: tag because Git stores the author in a
>separate field.
>
>> +/* Use duration as a reference, adjust the number of flow_limit,
>> + * when the duration is small, increase the flow-limit, and
>> vice versa */
>> +if (duration >= 1000) {
>> flow_limit /= duration / 1000;
>> -} else if (duration > 1300) {
>> -flow_limit = flow_limit * 3 / 4;
>> -} else if (duration < 1000 &&
>> - flow_limit < n_flows * 1000 / duration) {
>> -flow_limit += 1000;
>> +} else {
>> +flow_limit *= 1000 / duration;
>> }
>> flow_limit = MIN(ofproto_flow_limit, MAX(flow_limit, 1000));
>> atomic_store_relaxed(>flow_limit, flow_limit);
>
>The above is very abrupt. It always tries to adjust the flow limit
>upward or downward. I think that this is a bad idea, especially in the
>upward direction. If there are only a few flows, which only take a few
>milliseconds to revalidate, then it will keep increasing the flow limit
>upward until it overflows the range of unsigned int. It will happen
>very quickly, in fact: if duration is 1 ms three times in a row, then we
>will multiply flow_limit by 1,000,000,000 and overflow 32-bit UINT_MAX;
>if it happens six times in a row, we will overflow 64-bit.
>
Hi,Ben,
Thanks for your review.
It won't overflow, because of the following line of
code(https://github.com/openvswitch/ovs/blob/master/ofproto/ofproto-dpif-upcall.c#L974),which
makes it won't over `ofproto_flow_limit` .
For example, if currently flow-limit is 200,000(the default
ofproto_flow_limit), and duration is 1ms, it will become 200,000,000 ,which is
much less than 32-bit UINT_MAX(4,294,967,295).
And then, it wil be back to 200,000,because of the limtitaion mentioned above,
I think this is important.
>Furthermore, it doesn't work well even if we have longer durations. If
>revalidation takes 501 ms, then we can adjust the flow_limit upward, but
>this won't do it.
emm...though，it won't change when `501ms`， but it will change when `500ms` or
times of 2 or 5 .
If you think it's needed to make process more linear, we can change its type
from int to float.
what do you think?
>On the downward direction, this new code does nothing if the duration is
>less than 2 seconds. We want to aim for 1-second revalidation times.
>
In this code ,I changed the benchmark value from 2s and 1.3s to 1s. It aims for
1-second revalidation times.
Do I misunderstand your point? please let me know , thanks. The following is
the new code.
if (duration >= 1000) {
flow_limit /= duration / 1000;
} else {
flow_limit *= 1000 / duration;
}
flow_limit = MIN(ofproto_flow_limit, MAX(flow_limit, 1000));
>I don't think that this approach has been thought through very well.
>___
>dev mailing list
>d...@openvswitch.org
>https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Discussion on the logical rationality of flow-limit
Hi， Recently I encountered a TCP connection performance problem, the test tool is Apache benchmark. The OVS in my environment is set for hardware offload solution. The "Requests per second" is about 6000/s， it closed to non-offload solution. "flow-lmit" has a dynamic balance in udpif_revalidator, it will modify by the OVS condition（which is pind to "duration"）. In the revalidate function, when the number of flows is greater than twice the "flow-limit" , the delete flow operation will be triggered to delete all flows; when the number of flows is greater than the "flow-limit", the aging time will be adjusted to 0.1s, Slowly delete flow. I found that the reason for the poor performance is that when the number of flows in the datapath increases and the processing power of OVS decreases, a large number of flow deletions are generated. As we know, In the hardware offloading scenario, although there are a lot of flows, in fact, apart from the first packet, there is no need to process subsequent packets. In my opinion, the dynamic balance mechanism is very necessary, but we need to increase the value of “duration”, or provide some new switches for some high-performance scenarios, such as hardware offloading. Do we still need to restrict the number of flows so strictly? By the way, do you have another solution to resolve this? Thanks, Yun ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [OVN]Cookie of OpenFlow will not change, if UUID of logical-flow changes.
Hi,Numa, When I change the MTU of netork in OpenStack，the dhcp_options will also changes, and it will delete the old logical flow ,and create a new one for put_dhcp_opts. So the UUID of releated logical-flow will change. But,the cookie of OpenFlow in the allocated chassis not changed until we restart the ovn-controller. By the way ,the function is always OK. The version of OVS/OVN is 2.10. This situaiton will give us some trouble to track OpenFlow. What do you think? Thanks, Yun ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2] ovsdb-server: Allow OVSDB clients to specify the UUID for inserted rows.
Hi Ben,
It will be appreciated，if you give more explanation for the resaon
to summit this patch. In my opinion, it makes the "UUID" column be almost the
same with "name" column, if we need "name" column in the future?
At 2020-01-10 11:39:22, "Han Zhou" wrote:
>On Thu, Jan 9, 2020 at 12:48 PM Ben Pfaff wrote:
>>
>> Requested-by: Leonid Ryzhyk
>> Signed-off-by: Ben Pfaff
>> ---
>> v1->v2: Improve test as suggested by Flavio Fernandes.
>>
>> Documentation/ref/ovsdb-server.7.rst | 9 +
>> NEWS | 1 +
>> ovsdb/execution.c| 26 ++
>> ovsdb/transaction.c | 22 +-
>> ovsdb/transaction.h | 5 -
>> tests/ovsdb-execution.at | 24
>> tests/uuidfilt.py| 18 --
>> 7 files changed, 97 insertions(+), 8 deletions(-)
>>
>> diff --git a/Documentation/ref/ovsdb-server.7.rst
>b/Documentation/ref/ovsdb-server.7.rst
>> index bc533611cb4a..967761bdfb84 100644
>> --- a/Documentation/ref/ovsdb-server.7.rst
>> +++ b/Documentation/ref/ovsdb-server.7.rst
>> @@ -546,6 +546,15 @@ condition can be either a 3-element JSON array as
>described in the RFC or a
>> boolean value. In case of an empty array an implicit true boolean value
>will be
>> considered.
>>
>> +5.2.1 Insert
>> +
>> +
>> +As an extension, Open vSwitch 2.13 and later allow an optional ``uuid``
>member
>> +to specify the UUID for the new row. The specified UUID must be unique
>within
>> +the table when it is inserted and not the UUID of a row previously
>deleted
>> +within the transaction. If the UUID violates these rules, then the
>operation
>> +fails with a ``duplicate uuid`` error.
>> +
>> 5.2.6 Wait, 5.2.7 Commit, 5.2.9 Comment
>> ---
>>
>> diff --git a/NEWS b/NEWS
>> index 965facaf852d..d8f82cd18af0 100644
>> --- a/NEWS
>> +++ b/NEWS
>> @@ -34,6 +34,7 @@ Post-v2.12.0
>> interval is increased to 60 seconds for the connection to the
>> replication server. This value is configurable with the unixctl
>> command - ovsdb-server/set-active-ovsdb-server-probe-interval.
>> + * ovsdb-server: New OVSDB extension to allow clients to specify row
>UUIDs.
>>
>> v2.12.0 - 03 Sep 2019
>> -
>> diff --git a/ovsdb/execution.c b/ovsdb/execution.c
>> index f2cf3d72d45f..e45f3d6796a7 100644
>> --- a/ovsdb/execution.c
>> +++ b/ovsdb/execution.c
>> @@ -1,4 +1,4 @@
>> -/* Copyright (c) 2009, 2010, 2011, 2012, 2013, 2017 Nicira, Inc.
>> +/* Copyright (c) 2009, 2010, 2011, 2012, 2013, 2017, 2019 Nicira, Inc.
>> *
>> * Licensed under the Apache License, Version 2.0 (the "License");
>> * you may not use this file except in compliance with the License.
>> @@ -329,11 +329,12 @@ ovsdb_execute_insert(struct ovsdb_execution *x,
>struct ovsdb_parser *parser,
>> {
>> struct ovsdb_table *table;
>> struct ovsdb_row *row = NULL;
>> -const struct json *uuid_name, *row_json;
>> +const struct json *uuid_json, *uuid_name, *row_json;
>> struct ovsdb_error *error;
>> struct uuid row_uuid;
>>
>> table = parse_table(x, parser, "table");
>> +uuid_json = ovsdb_parser_member(parser, "uuid", OP_STRING |
>OP_OPTIONAL);
>> uuid_name = ovsdb_parser_member(parser, "uuid-name", OP_ID |
>OP_OPTIONAL);
>> row_json = ovsdb_parser_member(parser, "row", OP_OBJECT);
>> error = ovsdb_parser_get_error(parser);
>> @@ -341,6 +342,19 @@ ovsdb_execute_insert(struct ovsdb_execution *x,
>struct ovsdb_parser *parser,
>> return error;
>> }
>>
>> +if (uuid_json) {
>> +if (!uuid_from_string(_uuid, json_string(uuid_json))) {
>> +return ovsdb_syntax_error(uuid_json, NULL, "bad uuid");
>> +}
>> +
>> +if (!ovsdb_txn_may_create_row(table, _uuid)) {
>> +return ovsdb_syntax_error(uuid_json, "duplicate uuid",
>> + "This UUID would duplicate a UUID "
>> + "already present within the table
>or "
>> + "deleted within the same
>transaction.");
>> +}
>> +}
>> +
>> if (uuid_name) {
>> struct ovsdb_symbol *symbol;
>>
>> @@ -350,9 +364,13 @@ ovsdb_execute_insert(struct ovsdb_execution *x,
>struct ovsdb_parser *parser,
>>"This \"uuid-name\" appeared on an
>"
>>"earlier \"insert\" operation.");
>> }
>> -row_uuid = symbol->uuid;
>> +if (uuid_json) {
>> +symbol->uuid = row_uuid;
>> +} else {
>> +row_uuid = symbol->uuid;
>> +}
>> symbol->created = true;
>> -} else {
>> +} else if (!uuid_json) {
>> uuid_generate(_uuid);
>> }
>>
>> diff --git a/ovsdb/transaction.c b/ovsdb/transaction.c
>> index
Re: [ovs-dev] [OVN][RAFT] Follower refusing new entries from leader
Hi, Han, I do not encounter that problem these days after using this patch. I think there is no COMPACT in my environment. Actaully , I don't see any snap file in /var/lib/openvswitch. Thanks, Yun At 2019-12-04 10:01:16, "Han Zhou" wrote: Hi, Could you see if this patch fixes your problem? https://patchwork.ozlabs.org/patch/1203951/ Thanks, Han On Mon, Dec 2, 2019 at 12:28 AM Han Zhou wrote: Sorry for the late reply. It was holiday here. I didn't see such problem when there is no compaction. Did you see this problem when DB compaction didn't happen? The difference is that after compaction the RAFT log doesn't have any entries and all the data is in the snapshot. On Fri, Nov 29, 2019 at 12:11 AM taoyunupt wrote: Hi,Han Hope to receive your reply. Thanks, Yun 在 2019-11-28 16:17:07，"taoyunupt" 写道： Hi,Han Another question. NO COMPACT. If restart a follower , leader sender some entries during the break time, when it has started, if it also happend to this problem? What is the difference between simply restart and COMPACT with restart ? Thanks, Yun 在 2019-11-28 13:58:36，"taoyunupt" 写道： Hi,Han Thanks for your reply. I think maybe we can disconnect the failed follower from the Haproxy then synchronize the date, after all completed, reconnect it to Haproxy again. But I do not know how to synchronize actually. It is just my naive idea. Do you have some suggestion about how to fix this problem. If not very completed, I wii have a try. Thanks Yun 在 2019-11-28 11:47:55，"Han Zhou" 写道： On Wed, Nov 27, 2019 at 7:22 PM taoyunupt wrote: > > Hi, > My OVN cluster has 3 OVN-northd nodes, They are proxied by Haproxy with a > VIP. Recently, I restart OVN cluster frequently. One of the members report > the logs below. > After read the code and paper of RAFT, it seems normal process ,If the > follower does not find an entry in its log with the same index and term, then > it refuses the new entries. > I think it's reasonable to refuse. But, as we could not control Haproxy > or some proxy maybe, so it will happen error when an session assignate to the > failed follower. > > Does have some means or ways to solve this problem. Maybe we can kick off > the failed follower or disconnect it from the haproxy then synchronize the > date ? Hope to hear your suggestion. > > > 2019-11-27T14:22:17.060Z|00240|raft|INFO|rejecting append_request because > previous entry 1103,50975 not in local log (mismatch past end of log) > 2019-11-27T14:22:17.064Z|00241|raft|ERR|Dropped 34 log messages in last 12 > seconds (most recently, 0 seconds ago) due to excessive rate > 2019-11-27T14:22:17.064Z|00242|raft|ERR|internal error: deferred append_reply > message completed but not ready to send because message index 14890 is past > last synced index 0: a2b2 append_reply "mismatch past end of log": term=1103 > log_end=14891 result="inconsistency" > 2019-11-27T14:22:17.402Z|00243|raft|INFO|rejecting append_request because > previous entry 1103,50975 not in local log (mismatch past end of log) > > > [root@ovn1 ~]# ovs-appctl -t /var/run/openvswitch/ovnsb_db.ctl > cluster/status OVN_Southbound > a2b2 > Name: OVN_Southbound > Cluster ID: 4c54 (4c546513-77e3-4602-b211-2e200014ad79) > Server ID: a2b2 (a2b2a9c5-cf58-4724-8421-88fd5ca5d94d) > Address: tcp:10.254.8.209:6644 > Status: cluster member > Role: leader > Term: 1103 > Leader: self > Vote: self > > Log: [42052, 51009] > Entries not yet committed: 0 > Entries not yet applied: 0 > Connections: ->beaf ->9a33 <-9a33 <-beaf > Servers: > a2b2 (a2b2 at tcp:10.254.8.209:6644) (self) next_index=15199 > match_index=51008 > beaf (beaf at tcp:10.254.8.208:6644) next_index=51009 match_index=0 > 9a33 (9a33 at tcp:10.254.8.210:6644) next_index=51009 match_index=51008 > I think it is a bug. I noticed that this problem happens when the cluster is restarted after DB compaction. I mentioned it in one of the test cases: https://github.com/openvswitch/ovs/blob/master/tests/ovsdb-cluster.at#L252 I also mentioned another problem related to compaction: https://github.com/openvswitch/ovs/blob/master/tests/ovsdb-cluster.at#L239 I was planning to debug these but didn't get the time yet. I will try to find some time next week (it would be great if you could figure it out and submit patches). Thanks, Han ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [OVN][RAFT] Follower refusing new entries from leader
Hi,Han Hope to receive your reply. Thanks, Yun 在 2019-11-28 16:17:07，"taoyunupt" 写道： Hi,Han Another question. NO COMPACT. If restart a follower , leader sender some entries during the break time, when it has started, if it also happend to this problem? What is the difference between simply restart and COMPACT with restart ? Thanks, Yun 在 2019-11-28 13:58:36，"taoyunupt" 写道： Hi,Han Thanks for your reply. I think maybe we can disconnect the failed follower from the Haproxy then synchronize the date, after all completed, reconnect it to Haproxy again. But I do not know how to synchronize actually. It is just my naive idea. Do you have some suggestion about how to fix this problem. If not very completed, I wii have a try. Thanks Yun 在 2019-11-28 11:47:55，"Han Zhou" 写道： On Wed, Nov 27, 2019 at 7:22 PM taoyunupt wrote: > > Hi, > My OVN cluster has 3 OVN-northd nodes, They are proxied by Haproxy with a > VIP. Recently, I restart OVN cluster frequently. One of the members report > the logs below. > After read the code and paper of RAFT, it seems normal process ,If the > follower does not find an entry in its log with the same index and term, then > it refuses the new entries. > I think it's reasonable to refuse. But, as we could not control Haproxy > or some proxy maybe, so it will happen error when an session assignate to the > failed follower. > > Does have some means or ways to solve this problem. Maybe we can kick off > the failed follower or disconnect it from the haproxy then synchronize the > date ? Hope to hear your suggestion. > > > 2019-11-27T14:22:17.060Z|00240|raft|INFO|rejecting append_request because > previous entry 1103,50975 not in local log (mismatch past end of log) > 2019-11-27T14:22:17.064Z|00241|raft|ERR|Dropped 34 log messages in last 12 > seconds (most recently, 0 seconds ago) due to excessive rate > 2019-11-27T14:22:17.064Z|00242|raft|ERR|internal error: deferred append_reply > message completed but not ready to send because message index 14890 is past > last synced index 0: a2b2 append_reply "mismatch past end of log": term=1103 > log_end=14891 result="inconsistency" > 2019-11-27T14:22:17.402Z|00243|raft|INFO|rejecting append_request because > previous entry 1103,50975 not in local log (mismatch past end of log) > > > [root@ovn1 ~]# ovs-appctl -t /var/run/openvswitch/ovnsb_db.ctl > cluster/status OVN_Southbound > a2b2 > Name: OVN_Southbound > Cluster ID: 4c54 (4c546513-77e3-4602-b211-2e200014ad79) > Server ID: a2b2 (a2b2a9c5-cf58-4724-8421-88fd5ca5d94d) > Address: tcp:10.254.8.209:6644 > Status: cluster member > Role: leader > Term: 1103 > Leader: self > Vote: self > > Log: [42052, 51009] > Entries not yet committed: 0 > Entries not yet applied: 0 > Connections: ->beaf ->9a33 <-9a33 <-beaf > Servers: > a2b2 (a2b2 at tcp:10.254.8.209:6644) (self) next_index=15199 > match_index=51008 > beaf (beaf at tcp:10.254.8.208:6644) next_index=51009 match_index=0 > 9a33 (9a33 at tcp:10.254.8.210:6644) next_index=51009 match_index=51008 > I think it is a bug. I noticed that this problem happens when the cluster is restarted after DB compaction. I mentioned it in one of the test cases: https://github.com/openvswitch/ovs/blob/master/tests/ovsdb-cluster.at#L252 I also mentioned another problem related to compaction: https://github.com/openvswitch/ovs/blob/master/tests/ovsdb-cluster.at#L239 I was planning to debug these but didn't get the time yet. I will try to find some time next week (it would be great if you could figure it out and submit patches). Thanks, Han ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [OVN][RAFT] Follower refusing new entries from leader
Hi,Han Another question. NO COMPACT. If restart a follower , leader sender some entries during the break time, when it has started, if it also happend to this problem? What is the difference between simply restart and COMPACT with restart ? Thanks, Yun 在 2019-11-28 13:58:36，"taoyunupt" 写道： Hi,Han Thanks for your reply. I think maybe we can disconnect the failed follower from the Haproxy then synchronize the date, after all completed, reconnect it to Haproxy again. But I do not know how to synchronize actually. It is just my naive idea. Do you have some suggestion about how to fix this problem. If not very completed, I wii have a try. Thanks Yun 在 2019-11-28 11:47:55，"Han Zhou" 写道： On Wed, Nov 27, 2019 at 7:22 PM taoyunupt wrote: > > Hi, > My OVN cluster has 3 OVN-northd nodes, They are proxied by Haproxy with a > VIP. Recently, I restart OVN cluster frequently. One of the members report > the logs below. > After read the code and paper of RAFT, it seems normal process ,If the > follower does not find an entry in its log with the same index and term, then > it refuses the new entries. > I think it's reasonable to refuse. But, as we could not control Haproxy > or some proxy maybe, so it will happen error when an session assignate to the > failed follower. > > Does have some means or ways to solve this problem. Maybe we can kick off > the failed follower or disconnect it from the haproxy then synchronize the > date ? Hope to hear your suggestion. > > > 2019-11-27T14:22:17.060Z|00240|raft|INFO|rejecting append_request because > previous entry 1103,50975 not in local log (mismatch past end of log) > 2019-11-27T14:22:17.064Z|00241|raft|ERR|Dropped 34 log messages in last 12 > seconds (most recently, 0 seconds ago) due to excessive rate > 2019-11-27T14:22:17.064Z|00242|raft|ERR|internal error: deferred append_reply > message completed but not ready to send because message index 14890 is past > last synced index 0: a2b2 append_reply "mismatch past end of log": term=1103 > log_end=14891 result="inconsistency" > 2019-11-27T14:22:17.402Z|00243|raft|INFO|rejecting append_request because > previous entry 1103,50975 not in local log (mismatch past end of log) > > > [root@ovn1 ~]# ovs-appctl -t /var/run/openvswitch/ovnsb_db.ctl > cluster/status OVN_Southbound > a2b2 > Name: OVN_Southbound > Cluster ID: 4c54 (4c546513-77e3-4602-b211-2e200014ad79) > Server ID: a2b2 (a2b2a9c5-cf58-4724-8421-88fd5ca5d94d) > Address: tcp:10.254.8.209:6644 > Status: cluster member > Role: leader > Term: 1103 > Leader: self > Vote: self > > Log: [42052, 51009] > Entries not yet committed: 0 > Entries not yet applied: 0 > Connections: ->beaf ->9a33 <-9a33 <-beaf > Servers: > a2b2 (a2b2 at tcp:10.254.8.209:6644) (self) next_index=15199 > match_index=51008 > beaf (beaf at tcp:10.254.8.208:6644) next_index=51009 match_index=0 > 9a33 (9a33 at tcp:10.254.8.210:6644) next_index=51009 match_index=51008 > I think it is a bug. I noticed that this problem happens when the cluster is restarted after DB compaction. I mentioned it in one of the test cases: https://github.com/openvswitch/ovs/blob/master/tests/ovsdb-cluster.at#L252 I also mentioned another problem related to compaction: https://github.com/openvswitch/ovs/blob/master/tests/ovsdb-cluster.at#L239 I was planning to debug these but didn't get the time yet. I will try to find some time next week (it would be great if you could figure it out and submit patches). Thanks, Han ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [OVN][RAFT] Follower refusing new entries from leader
Hi,Han Thanks for your reply. I think maybe we can disconnect the failed follower from the Haproxy then synchronize the date, after all completed, reconnect it to Haproxy again. But I do not know how to synchronize actually. It is just my naive idea. Do you have some suggestion about how to fix this problem. If not very completed, I wii have a try. Thanks Yun 在 2019-11-28 11:47:55，"Han Zhou" 写道： On Wed, Nov 27, 2019 at 7:22 PM taoyunupt wrote: > > Hi, > My OVN cluster has 3 OVN-northd nodes, They are proxied by Haproxy with a > VIP. Recently, I restart OVN cluster frequently. One of the members report > the logs below. > After read the code and paper of RAFT, it seems normal process ,If the > follower does not find an entry in its log with the same index and term, then > it refuses the new entries. > I think it's reasonable to refuse. But, as we could not control Haproxy > or some proxy maybe, so it will happen error when an session assignate to the > failed follower. > > Does have some means or ways to solve this problem. Maybe we can kick off > the failed follower or disconnect it from the haproxy then synchronize the > date ? Hope to hear your suggestion. > > > 2019-11-27T14:22:17.060Z|00240|raft|INFO|rejecting append_request because > previous entry 1103,50975 not in local log (mismatch past end of log) > 2019-11-27T14:22:17.064Z|00241|raft|ERR|Dropped 34 log messages in last 12 > seconds (most recently, 0 seconds ago) due to excessive rate > 2019-11-27T14:22:17.064Z|00242|raft|ERR|internal error: deferred append_reply > message completed but not ready to send because message index 14890 is past > last synced index 0: a2b2 append_reply "mismatch past end of log": term=1103 > log_end=14891 result="inconsistency" > 2019-11-27T14:22:17.402Z|00243|raft|INFO|rejecting append_request because > previous entry 1103,50975 not in local log (mismatch past end of log) > > > [root@ovn1 ~]# ovs-appctl -t /var/run/openvswitch/ovnsb_db.ctl > cluster/status OVN_Southbound > a2b2 > Name: OVN_Southbound > Cluster ID: 4c54 (4c546513-77e3-4602-b211-2e200014ad79) > Server ID: a2b2 (a2b2a9c5-cf58-4724-8421-88fd5ca5d94d) > Address: tcp:10.254.8.209:6644 > Status: cluster member > Role: leader > Term: 1103 > Leader: self > Vote: self > > Log: [42052, 51009] > Entries not yet committed: 0 > Entries not yet applied: 0 > Connections: ->beaf ->9a33 <-9a33 <-beaf > Servers: > a2b2 (a2b2 at tcp:10.254.8.209:6644) (self) next_index=15199 > match_index=51008 > beaf (beaf at tcp:10.254.8.208:6644) next_index=51009 match_index=0 > 9a33 (9a33 at tcp:10.254.8.210:6644) next_index=51009 match_index=51008 > I think it is a bug. I noticed that this problem happens when the cluster is restarted after DB compaction. I mentioned it in one of the test cases: https://github.com/openvswitch/ovs/blob/master/tests/ovsdb-cluster.at#L252 I also mentioned another problem related to compaction: https://github.com/openvswitch/ovs/blob/master/tests/ovsdb-cluster.at#L239 I was planning to debug these but didn't get the time yet. I will try to find some time next week (it would be great if you could figure it out and submit patches). Thanks, Han ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [OVN][RAFT] Follower refusing new entries from leader
Hi, My OVN cluster has 3 OVN-northd nodes, They are proxied by Haproxy with a VIP. Recently, I restart OVN cluster frequently. One of the members report the logs below. After read the code and paper of RAFT, it seems normal process ,If the follower does not find an entry in its log with the same index and term, then it refuses the new entries. I think it's reasonable to refuse. But, as we could not control Haproxy or some proxy maybe, so it will happen error when an session assignate to the failed follower. Does have some means or ways to solve this problem. Maybe we can kick off the failed follower or disconnect it from the haproxy then synchronize the date ? Hope to hear your suggestion. 2019-11-27T14:22:17.060Z|00240|raft|INFO|rejecting append_request because previous entry 1103,50975 not in local log (mismatch past end of log) 2019-11-27T14:22:17.064Z|00241|raft|ERR|Dropped 34 log messages in last 12 seconds (most recently, 0 seconds ago) due to excessive rate 2019-11-27T14:22:17.064Z|00242|raft|ERR|internal error: deferred append_reply message completed but not ready to send because message index 14890 is past last synced index 0: a2b2 append_reply "mismatch past end of log": term=1103 log_end=14891 result="inconsistency" 2019-11-27T14:22:17.402Z|00243|raft|INFO|rejecting append_request because previous entry 1103,50975 not in local log (mismatch past end of log) [root@ovn1 ~]# ovs-appctl -t /var/run/openvswitch/ovnsb_db.ctl cluster/status OVN_Southbound a2b2 Name: OVN_Southbound Cluster ID: 4c54 (4c546513-77e3-4602-b211-2e200014ad79) Server ID: a2b2 (a2b2a9c5-cf58-4724-8421-88fd5ca5d94d) Address: tcp:10.254.8.209:6644 Status: cluster member Role: leader Term: 1103 Leader: self Vote: self Log: [42052, 51009] Entries not yet committed: 0 Entries not yet applied: 0 Connections: ->beaf ->9a33 <-9a33 <-beaf Servers: a2b2 (a2b2 at tcp:10.254.8.209:6644) (self) next_index=15199 match_index=51008 beaf (beaf at tcp:10.254.8.208:6644) next_index=51009 match_index=0 9a33 (9a33 at tcp:10.254.8.210:6644) next_index=51009 match_index=51008 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn v2 00/13] OVN Interconnection
Get it. Thanks Han. At 2019-11-20 11:51:17, "Han Zhou" wrote: Hi Yun, This feature in OVN doesn't require or put limit on the CMS systems such as Neutron, or kubernetes. To utilize this feature from CMS system, the CMS integration may be needed, e.g. add support in networking-ovn Neutron plugin or networking-ovn k8s plugin. However, the scenario you described that multiple AZs managed by a single global Neutron is not directly related to this feature. The first thing is to add support to networking-ovn so that a single neutron can manage multiple OVN deployments, if that is a realistic use case. That's needed even without this ovn-interconnection feature. However, it seems Neutron interface doesn't have the AZ concept (as far as I know, unless it is added in recent releases), so it seems not straightforward to support such feature in networking-ovn. To support it, I guess you will need something like OVN control plane federation, which is a completely different problem from the one that is going to solved by the ovn-interconnection feature. Thanks, Han On Tue, Nov 19, 2019 at 7:30 PM taoyunupt wrote: Hi,Han,Numan, If I am not mistake, each AZ(OVN deployment) must have a corresponding networking-ovn(neurton). But if we want to have a global neutron above AZ, that is, multi AZ(OVN deployment) is controlled by one neutron, this would be not work? Am I right ? Did you consider this situation? Thanks, Yun At 2019-11-18 14:55:26, "Numan Siddique" wrote: >On Mon, Nov 18, 2019 at 8:22 AM Han Zhou wrote: >> >> On Sat, Nov 16, 2019 at 4:03 AM Numan Siddique wrote: >> > >> > >> > >> > On Fri, Nov 15, 2019 at 1:18 PM Han Zhou wrote: >> >> >> >> >> >> >> >> On Thu, Nov 14, 2019 at 10:25 PM Numan Siddique wrote: >> >> > >> >> > On Thu, Nov 14, 2019 at 11:44 PM Han Zhou wrote: >> >> > > >> >> > > On Wed, Nov 13, 2019 at 10:27 AM Numan Siddique >> wrote: >> >> > > > >> >> > > > On Thu, Oct 31, 2019 at 2:43 AM Han Zhou wrote: >> >> > > > > >> >> > > > > The series supports interconnecting multiple OVN deployments >> (e.g. >> >> > > located at >> >> > > > > multiple data centers) through logical routers connected with >> tansit >> >> > > logical >> >> > > > > switches with overlay tunnels, managed through OVN control >> plane. See >> >> > > the >> >> > > > > ovn-architecture.rst document updates for more details, and find >> the >> >> > > > > instructions in Documentation/tutorials/ovn-interconnection.rst. >> >> > > > > >> >> > > > > Han Zhou (13): >> >> > > > > ovn-architecture: Add documentation for OVN interconnection >> feature. >> >> > > > > ovn-inb: Interconnection northbound DB schema and CLI. >> >> > > > > ovn-isb: Interconnection southbound DB schema and CLI. >> >> > > > > ovn-ic: Interconnection controller with AZ registeration. >> >> > > > > ovn-northd.c: Refactor allocate_tnlid. >> >> > > > > ovn-ic: Transit switch controller. >> >> > > > > ovn-sb: Add columns is_interconn and is_remote to Chassis. >> >> > > > > ovn-ic: Interconnection gateway controller. >> >> > > > > ovn-ic: Interconnection port controller. >> >> > > > > ovn.at: e2e test for OVN interconnection. >> >> > > > > ovn-ctl: Refactor to reduce redundant code. >> >> > > > > ovn-ctl: Support commands for interconnection. >> >> > > > > tutorial: Add tutorial for OVN Interconnection. >> >> > > > > >> >> > > > >> >> > > > Hi Han, >> >> > > > >> >> > > > Thanks for working on this feature. It's an interesting use case. >> >> > > > >> >> > > > I had a quick look at all the patches. >> >> > > > >> >> > > >> >> > > Numan, thanks a lot for the thorough review! Please see my response >> inlined. >> >> > > >> >> > > > I have few comments >> >> > > > >> >> > > > 1. I would suggest to rename the DBs as ovn-ic-nb.ovsschema (and >> the >> >> > > > same for
Re: [ovs-dev] [PATCH ovn v2 00/13] OVN Interconnection
Hi,Han,Numan, If I am not mistake, each AZ(OVN deployment) must have a corresponding networking-ovn(neurton). But if we want to have a global neutron above AZ, that is, multi AZ(OVN deployment) is controlled by one neutron, this would be not work? Am I right ? Did you consider this situation? Thanks, Yun At 2019-11-18 14:55:26, "Numan Siddique" wrote: >On Mon, Nov 18, 2019 at 8:22 AM Han Zhou wrote: >> >> On Sat, Nov 16, 2019 at 4:03 AM Numan Siddique wrote: >> > >> > >> > >> > On Fri, Nov 15, 2019 at 1:18 PM Han Zhou wrote: >> >> >> >> >> >> >> >> On Thu, Nov 14, 2019 at 10:25 PM Numan Siddique wrote: >> >> > >> >> > On Thu, Nov 14, 2019 at 11:44 PM Han Zhou wrote: >> >> > > >> >> > > On Wed, Nov 13, 2019 at 10:27 AM Numan Siddique >> wrote: >> >> > > > >> >> > > > On Thu, Oct 31, 2019 at 2:43 AM Han Zhou wrote: >> >> > > > > >> >> > > > > The series supports interconnecting multiple OVN deployments >> (e.g. >> >> > > located at >> >> > > > > multiple data centers) through logical routers connected with >> tansit >> >> > > logical >> >> > > > > switches with overlay tunnels, managed through OVN control >> plane. See >> >> > > the >> >> > > > > ovn-architecture.rst document updates for more details, and find >> the >> >> > > > > instructions in Documentation/tutorials/ovn-interconnection.rst. >> >> > > > > >> >> > > > > Han Zhou (13): >> >> > > > > ovn-architecture: Add documentation for OVN interconnection >> feature. >> >> > > > > ovn-inb: Interconnection northbound DB schema and CLI. >> >> > > > > ovn-isb: Interconnection southbound DB schema and CLI. >> >> > > > > ovn-ic: Interconnection controller with AZ registeration. >> >> > > > > ovn-northd.c: Refactor allocate_tnlid. >> >> > > > > ovn-ic: Transit switch controller. >> >> > > > > ovn-sb: Add columns is_interconn and is_remote to Chassis. >> >> > > > > ovn-ic: Interconnection gateway controller. >> >> > > > > ovn-ic: Interconnection port controller. >> >> > > > > ovn.at: e2e test for OVN interconnection. >> >> > > > > ovn-ctl: Refactor to reduce redundant code. >> >> > > > > ovn-ctl: Support commands for interconnection. >> >> > > > > tutorial: Add tutorial for OVN Interconnection. >> >> > > > > >> >> > > > >> >> > > > Hi Han, >> >> > > > >> >> > > > Thanks for working on this feature. It's an interesting use case. >> >> > > > >> >> > > > I had a quick look at all the patches. >> >> > > > >> >> > > >> >> > > Numan, thanks a lot for the thorough review! Please see my response >> inlined. >> >> > > >> >> > > > I have few comments >> >> > > > >> >> > > > 1. I would suggest to rename the DBs as ovn-ic-nb.ovsschema (and >> the >> >> > > > same for ovn-isb). >> >> > > > The DB name is - OVN_IC_Northbound. So it would make sense to >> have >> >> > > > - ovn-ic-nb.ovsschema >> >> > > > I would also suggest to rename the utilities to ovn-ic-nbctl >> and >> >> > > > ovn-ic-sbctl. >> >> > > > With ovn-inbctl/ovn-isbctl, it is really confusing. >> >> > > > >> >> > > Sure, I felt not quite convenient with two dashes in a command name. >> I >> >> > > agree that ovn-ic-nbctl and ovn-ic-sbctl are more clear. I can >> change it. >> >> > > >> >> > > > 2. ovn-ic service writes to interconnect south db, ovn north db and >> >> > > > ovn south db. Writing to ic south db and >> >> > > > ovn north db is fine. But it seems a little odd for ovn-ic to >> >> > > > write to south db. From what I understand it writes >> >> > > > to south db for 3 purposes >> >> > > > a. Updating the tunnel_key column of datapath_binding >> >> > > > representing the transit switch >> >> > > > b. Updating the key column of port_binding representing the >> >> > > > logical router port connecting to the transit switch. >> >> > > > c. Creating chassis rows for remote gateway chassis. >> >> > > > >> >> > > >I think it's better if ovn-ic can delegate all these to >> ovn-northd. >> >> > > > For (a) and (b), ovn-ic can set the generated tunnel key >> >> > > >in the other_config/options column of Logical switch/Logical >> switch >> >> > > > port. ovn-northd can internally set this value to >> >> > > >the south db. >> >> > > > >> >> > > >For (c), I think its better we add another table - >> Remote_Chassis >> >> > > > (or some other appropriate name) . ovn-ic will create rows >> >> > > >in this table for each remote chassis and ovn-northd will create >> >> > > > chassis row in south db. >> >> > > >We already have Gateway_Chassis table in North db. So I think >> it's >> >> > > > fine if we add Remote_Chassis table. The only odd thing >> >> > > >would be is to store the encap details in North db. >> >> > > > >> >> > > >With this, ovn-ic, doesn't need to worry about syncing between >> >> > > > interconnect south db and ovn south db. In my opinion ovn-ic >> >> > > >should act more like CMS to each availability zone and hence >> should >> >> > > > not do any write transactions to
Re: [ovs-dev] [OVN][RAFT]Why left server cannot be added back to
Hi，Ben,
I am agreed that ，under normal circumstances， there is no need to
allow left server back to origin server . But I met some strange situation. For
example ,sometimes, one server may be with two diffrent UUIDs recorded by
Leader server.
I think if the left server could be back to origin server, it will
be a easy solution to solve many strange problems.
Thanks,
Yun
At 2019-11-06 05:31:25, "Ben Pfaff" wrote:
>On Tue, Nov 05, 2019 at 08:10:41PM +0800, taoyunupt wrote:
>> Hi,Numan,
>> When I run OVN/RAFT cluster, I found a server(which
>> initiative to leave or be kicked off ) ,cannot be added back to origin
>> cluster. I found the code as following, can you tell me the reason , many
>> thanks!
>>
>>
>> case RAFT_REC_NOTE:
>> if (!strcmp(r->note, "left")) {
>> return ovsdb_error(NULL, "record %llu indicates server has left "
>>"the cluster; it cannot be added back (use "
>>"\"ovsdb-tool join-cluster\" to add a new "
>>"server)", rec_idx);
>
>The Raft dissertation doesn't contemplate the possibility of a server
>re-joining a cluster. Allowing it would add new corner cases that
>aren't worth dealing with.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [OVN][RAFT]Why left server cannot be added back to
Hi,Numan,
When I run OVN/RAFT cluster, I found a server(which initiative
to leave or be kicked off ) ,cannot be added back to origin cluster. I found
the code as following, can you tell me the reason , many thanks!
case RAFT_REC_NOTE:
if (!strcmp(r->note, "left")) {
return ovsdb_error(NULL, "record %llu indicates server has left "
"the cluster; it cannot be added back (use "
"\"ovsdb-tool join-cluster\" to add a new "
"server)", rec_idx);
Thanks,
Yun
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Does have any plan or blueprint to support fwaas and vpnaas in ovn/networking-ovn(openstack)
Dear all, As far as I know , ovn/networking-ovn(support) dose not support fwaas and vpnaas.So, does have any plan or blueprint to support fwaas and vpnaas in ovn/networking-ovn(openstack)? Yours , yunxiang ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] how to enable the log of ovn
Dear friends, Sorry to disturb. I have use ovn with openstasck for a while time,but i still do not know how to enable the log of ovn. There are only logging options in the manpage or the help of ovn-nbctl/ovn-sbctl,but no any logging command. When i excute cmd of 'ovn-nbctl --syslog-method=libc --verbose=dbg' or others similar,the print is 'ovn-nbctl: missing command name (use --help for help)' Regards, Yunxiang ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [ovs-discuss] which kernel module patch could repair the support of meter
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" 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 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" 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 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(_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(_action, "ip.dscp = %"PRId64"; next;",
>> >> qos->value_action[j]);
>> >> ovn_lflow_add(lflows, od, stage,
>> >> qos->priority,
>> >> qos->match, ds_cstr(_action));
>> >> ds_destroy(_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(_action,
>> >> "set_meter(%"PRId64&quo
Re: [ovs-dev] [ovs-discuss] which kernel module patch could repair the support of meter
yep, I want to backport meter support for an older kernel. But I need to know
which patch of the support for meters. So ,I hope you could give me the
address of this patch.Regards,
yunxiang
At 2019-01-29 09:32:31, "Justin Pettit" wrote:
>I'm afraid that I don't understand the question. Are you asking how you'd
>backport meter support for an older kernel? If so, you'd need to talk to the
>Centos/Red Hat maintainers.
>
>--Justin
>
>
>> On Jan 28, 2019, at 5:29 PM, taoyunupt wrote:
>>
>> 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" 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 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" 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 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(_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(_action, "ip.dscp = %"PRId64";
>> >> >> next;",
>> >&g
Re: [ovs-dev] [ovs-discuss] which kernel module patch could repair the support of meter
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" 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 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(_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(_action, "ip.dscp = %"PRId64"; next;",
>> qos->value_action[j]);
>> ovn_lflow_add(lflows, od, stage,
>> qos->priority,
>> qos->match, ds_cstr(_action));
>> ds_destroy(_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(_action,
>> "set_meter(%"PRId64", %"PRId64"); next;",
>> rate, burst);
>> } else {
>> ds_put_format(_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(_action));
>> ds_destroy(_action);
>> }
>> }
>> }
>>
>>
>>
>>
>>
>> At 2019-01-28 15:15:51, "Justin Pettit" 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 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,
>&g
Re: [ovs-dev] [ovs-discuss] which kernel module patch could repair the support of meter
Thanks justin!
You have gives me a great help!
Regards,
Yunxiang
At 2019-01-28 15:43:24, "Justin Pettit" 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 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(_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(_action, "ip.dscp = %"PRId64"; next;",
>> qos->value_action[j]);
>> ovn_lflow_add(lflows, od, stage,
>> qos->priority,
>> qos->match, ds_cstr(_action));
>> ds_destroy(_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(_action,
>> "set_meter(%"PRId64", %"PRId64"); next;",
>> rate, burst);
>> } else {
>> ds_put_format(_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(_action));
>> ds_destroy(_action);
>> }
>> }
>> }
>>
>>
>>
>>
>>
>> At 2019-01-28 15:15:51, "Justin Pettit" 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 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
>> >>
>> >>
>> >>
>> >>
>> >>
>
Re: [ovs-dev] [ovs-discuss] which kernel module patch could repair the support of meter
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(_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(_action, "ip.dscp = %"PRId64"; next;", |
| | qos->value_action[j]); |
| | ovn_lflow_add(lflows, od, stage, |
| | qos->priority, |
| | qos->match, ds_cstr(_action)); |
| | ds_destroy(_action); |
| | } |
| | } |
| | |
| | for (size_t n = 0; n < qos->n_bandwidth; n++) { |
| | if (!strcmp(qos->key_bandwidth[n], "rate")) { |
| | rate = qos->value_bandwidth[n]; |
| | } elseif (!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(_action, |
| | "set_meter(%"PRId64", %"PRId64"); next;", |
| | rate, burst); |
| | } else { |
| | ds_put_format(_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(_action)); |
| | ds_destroy(_action); |
| | } |
| | } |
| | } |
At 2019-01-28 15:15:51, "Justin Pettit" 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 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" 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 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
>>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [ovs-discuss] which kernel module patch could repair the support of meter
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" 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 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 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] which kernel module patch could repair the support of meter
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 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
