| *** troulouliou_div2 has quit IRC | 00:26 | |
| *** armax has quit IRC | 00:39 | |
| *** dceara has quit IRC | 00:59 | |
| *** acidfoo has quit IRC | 00:59 | |
| *** acidfoo has joined #openvswitch | 01:05 | |
| *** acidfoo has quit IRC | 02:00 | |
| *** acidfoo has joined #openvswitch | 02:06 | |
| *** dholler has quit IRC | 02:15 | |
| *** acidfoo has quit IRC | 02:16 | |
| *** acidfoo has joined #openvswitch | 02:20 | |
| *** dholler has joined #openvswitch | 02:29 | |
| *** psahoo has joined #openvswitch | 02:33 | |
| *** acidfoo has quit IRC | 03:15 | |
| *** dcbw has quit IRC | 04:07 | |
| *** duso has quit IRC | 06:05 | |
| *** duso has joined #openvswitch | 06:06 | |
| *** mmirecki has joined #openvswitch | 06:08 | |
| *** FH_thecat has quit IRC | 06:44 | |
| *** slaweq has joined #openvswitch | 06:48 | |
| *** eelco has joined #openvswitch | 06:51 | |
| *** tbachman_ has joined #openvswitch | 06:51 | |
| *** tbachman has quit IRC | 06:52 | |
| *** tbachman_ is now known as tbachman | 06:52 | |
| *** yogananth has quit IRC | 07:10 | |
| *** yogananth has joined #openvswitch | 07:10 | |
| *** yogananth has quit IRC | 07:24 | |
| *** yogananth has joined #openvswitch | 07:24 | |
| *** jaicaa has quit IRC | 07:31 | |
| *** jaicaa has joined #openvswitch | 07:33 | |
| *** cpaelzer has quit IRC | 07:56 | |
| *** jbenet has quit IRC | 07:56 | |
| *** flaviof has quit IRC | 07:56 | |
| *** mnasiadka has quit IRC | 07:56 | |
| *** Anticimex has quit IRC | 07:56 | |
| *** mepholic has quit IRC | 07:56 | |
| *** Nirkus has quit IRC | 07:56 | |
| *** cpaelzer has joined #openvswitch | 08:01 | |
| *** jbenet has joined #openvswitch | 08:01 | |
| *** flaviof has joined #openvswitch | 08:01 | |
| *** mnasiadka has joined #openvswitch | 08:01 | |
| *** Anticimex has joined #openvswitch | 08:01 | |
| *** mepholic has joined #openvswitch | 08:01 | |
| *** Nirkus has joined #openvswitch | 08:01 | |
| *** dceara has joined #openvswitch | 08:29 | |
| *** ktraynor has joined #openvswitch | 08:29 | |
| *** dceara has joined #openvswitch | 08:32 | |
| *** livelace has joined #openvswitch | 08:53 | |
| *** zhouhan_ has quit IRC | 09:07 | |
| *** zhouhan has joined #openvswitch | 09:07 | |
| *** livelace has quit IRC | 09:16 | |
| *** theodotos[m] has quit IRC | 09:40 | |
| *** theodotos[m] has joined #openvswitch | 09:56 | |
| *** thaller has quit IRC | 09:57 | |
| *** thaller has joined #openvswitch | 09:57 | |
| *** duso has quit IRC | 10:16 | |
| *** duso has joined #openvswitch | 10:17 | |
| *** timothy has joined #openvswitch | 10:25 | |
| *** bern has joined #openvswitch | 10:34 | |
| *** darkemon has quit IRC | 10:50 | |
| *** darkemon has joined #openvswitch | 10:53 | |
| *** eelco has quit IRC | 11:08 | |
| *** eelco has joined #openvswitch | 11:08 | |
| *** yamamoto has joined #openvswitch | 11:26 | |
| *** livelace has joined #openvswitch | 11:38 | |
| *** thaller has quit IRC | 12:27 | |
| *** thaller has joined #openvswitch | 12:27 | |
| *** thaller has quit IRC | 12:27 | |
| *** thaller has joined #openvswitch | 12:27 | |
| *** thaller has quit IRC | 12:28 | |
| *** thaller has joined #openvswitch | 12:28 | |
| *** thaller has quit IRC | 12:28 | |
| *** thaller has joined #openvswitch | 12:29 | |
| *** armax has joined #openvswitch | 12:33 | |
| *** bostondriver has joined #openvswitch | 12:39 | |
| *** yamamoto has quit IRC | 12:54 | |
| *** yamamoto has joined #openvswitch | 12:54 | |
| *** yamamoto has quit IRC | 14:02 | |
| *** yamamoto has joined #openvswitch | 14:02 | |
| *** acidfoo has joined #openvswitch | 14:05 | |
| *** yamamoto has quit IRC | 14:07 | |
| *** slaweq_ has joined #openvswitch | 14:14 | |
| *** slaweq has quit IRC | 14:14 | |
| *** yamamoto has joined #openvswitch | 14:18 | |
| *** slaweq_ has quit IRC | 14:32 | |
| *** dcbw has joined #openvswitch | 14:34 | |
| *** slaweq has joined #openvswitch | 14:34 | |
| *** eelco has quit IRC | 15:22 | |
| *** livelace has quit IRC | 15:26 | |
| *** livelace has joined #openvswitch | 15:34 | |
| *** mmirecki has quit IRC | 16:04 | |
| *** troulouliou_div2 has joined #openvswitch | 16:19 | |
| *** mmirecki has joined #openvswitch | 16:30 | |
| *** troulouliou_div2 has quit IRC | 16:46 | |
| *** mmirecki has quit IRC | 16:52 | |
| *** troulouliou_div2 has joined #openvswitch | 16:59 | |
| *** mmirecki has joined #openvswitch | 17:01 | |
| *** mmirecki has quit IRC | 17:08 | |
| *** blp has joined #openvswitch | 17:13 | |
| blp | good day all | 17:13 |
|---|---|---|
| *** mmirecki has joined #openvswitch | 17:14 | |
| *** ryzhyk has joined #openvswitch | 17:15 | |
| blp | Are we all assembled? | 17:15 |
| blp | Haven't seen much from anyone yet. | 17:15 |
| *** mmichelson_ has quit IRC | 17:15 | |
| zhouhan | Hi | 17:16 |
| dceara | Hi | 17:16 |
| *** mmichelson has joined #openvswitch | 17:16 | |
| *** aginwala has joined #openvswitch | 17:16 | |
| blp | I have good news, I have all the tests passing with the ddlog implementaiton of ovn-northd. | 17:16 |
| ryzhyk | hi | 17:16 |
| mmichelson | I had to drop, did someone #startmeeting? | 17:16 |
| blp | no | 17:16 |
| numans | Hi | 17:16 |
| blp | go ahead | 17:16 |
| numans | mmichelson, no | 17:16 |
| blp | I forgot | 17:16 |
| mmichelson | #startmeeting ovn-community-development-discussion | 17:16 |
| openstack | Meeting started Thu May 7 17:16:42 2020 UTC and is due to finish in 60 minutes. The chair is mmichelson. Information about MeetBot at http://wiki.debian.org/MeetBot. | 17:16 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:16 |
| openstack | The meeting name has been set to 'ovn_community_development_discussion' | 17:16 |
| blp | Ah, let me restart the one thing I said. | 17:16 |
| blp | I have good news, I have all the tests passing with the ddlog implementaiton of ovn-northd. | 17:16 |
| numans | that's great. | 17:16 |
| zhouhan | blp: wonderful | 17:17 |
| mmichelson | blp, Awesome! | 17:17 |
| blp | I also rebased against OVN master yesterday, | 17:17 |
| blp | which made some tests fail because there are new features, | 17:17 |
| blp | but it shouldn't take long to impelemnt them. | 17:17 |
| _lore_ | hi all, sorry to be late | 17:17 |
| numans | blp++ | 17:17 |
| blp | Then, we'll work on performance. ryzhyk will probably be the real source of power there. | 17:17 |
| flaviof | hi all | 17:18 |
| mmichelson | blp, OK, with regards to performance, do you already have some known problems or is it a matter of running tests and tweaking based on how they go? | 17:19 |
| blp | mmichelson: Haven't even tried anything performance wise yet. | 17:19 |
| blp | I just assume there'll need some work. | 17:19 |
| mmichelson | Got it | 17:20 |
| blp | At the very least we need to run benchmarks to compare performance. | 17:20 |
| *** mmirecki has quit IRC | 17:21 | |
| numans | blp, We have a test setup for performance testing. I think we can trigger a run with your branch. I think dceara has plans to do that. | 17:22 |
| *** anilvenkata has quit IRC | 17:22 | |
| mmichelson | Yeah, and with an up-to-date ovn-northd-ddlog implementation, this should be real interesting. | 17:23 |
| blp | I'll keep everyone up-to-date. | 17:23 |
| blp | That's all I've got. | 17:23 |
| _lore_ | can I go next? | 17:23 |
| mmichelson | go for it! | 17:24 |
| _lore_ | this week I worked on locking feature of ovn-northd and I spotted this issue | 17:24 |
| _lore_ | I have a cluster with 3 ovn-northd, one active and the other in standby | 17:24 |
| _lore_ | if I put the interface on active northd down the cluster does not recover | 17:25 |
| _lore_ | I mean, the other 2 remain in standby | 17:25 |
| _lore_ | I think because the active does not relase the lock | 17:26 |
| _lore_ | is there any feature on server side to take care of it? | 17:26 |
| zhouhan | ovsdb server named lock should release when the connection lost is detected | 17:27 |
| _lore_ | zhouhan: is the detection done on client side? | 17:27 |
| zhouhan | _lore_: it is on the server side | 17:27 |
| blp | When the server detects that a connection has broken, that releases any locks that the connection held. | 17:28 |
| _lore_ | ok, so for some reason it does not work in my case | 17:28 |
| zhouhan | _lore_: is the probe disabled? | 17:28 |
| _lore_ | need to check, it is default in ovn-fake-multinode | 17:28 |
| _lore_ | numans: ..^ | 17:28 |
| _lore_ | I will double check | 17:30 |
| _lore_ | anyway I added some unixctl commands to check the connection status on ovn-northd | 17:30 |
| _lore_ | I will post the patch later today | 17:31 |
| numans | _lore_, I think it configures to 180 seconds. | 17:31 |
| _lore_ | ack, thx | 17:31 |
| _lore_ | one question, what happen if the connection is flapping? | 17:32 |
| blp | From the point of view of the probe, either it succeeds or fails. | 17:33 |
| mmichelson | Sounds like it's at the mercy of the probe interval. So if the probe interval is short, then flapping may cause a premature release of the lock | 17:33 |
| blp | If one particular database connection is flapping, and the probe sees a failure, then it means that a backup will get the connection. | 17:33 |
| blp | the lock, i mean | 17:33 |
| blp | If that backup is more reliable, then that's a good thing. | 17:34 |
| _lore_ | ok, thx | 17:34 |
| _lore_ | I will try | 17:34 |
| _lore_ | that's all from my side | 17:34 |
| zhouhan | May I go next | 17:35 |
| zhouhan | I continued working on the dp_hash fastpath v.s. slowpath inconsistency problem. I back ported the upstream kernel fix to OVS tree and it solved the inconsistency problem for same flow. | 17:35 |
| zhouhan | However, it doesn’t solve the "same 5-tuple same bucket” requirement, because the dp_hash generated by socket is random. | 17:35 |
| mmichelson | Would numan's patch for specifying hash fields help with that sort of consistency? | 17:36 |
| mmichelson | Or is this related to that? | 17:36 |
| zhouhan | Here is the backport patch: https://patchwork.ozlabs.org/project/openvswitch/patch/1588554154-30608-1-git-send-email-hzhou@ovn.org/ | 17:36 |
| numans | zhouhan, Yesterday I tested and with Fedora 32 with 5.6.8+ kernel and with ovs master, I noticed that the same bucket is selected. | 17:37 |
| zhouhan | mmichelson: yes, numan's patch enables changing to "hash" instead of "dp_hash", which solves the requirement. However, it would be a performance degrade compares to dp_hash. | 17:37 |
| numans | with distro kernel datapath module | 17:37 |
| numans | zhouhan, I'll retest again to be sure. | 17:38 |
| zhouhan | numans: yes, in some environment it is not reproduced, even with old kernel, I noticed that as well. | 17:38 |
| numans | Ok. | 17:38 |
| zhouhan | blp: do you know what's the general practice of backporting kernel patch? I thought the author would usually backport to OVS tree, but it seems that doesn;t always happend | 17:39 |
| zhouhan | For the dp_hash consistency problem, here is more discussion: https://mail.openvswitch.org/pipermail/ovs-discuss/2020-May/050001.html | 17:39 |
| blp | Sometimes authors backport, but when they don't, someone else has to do it. | 17:39 |
| numans | blp, Will using selection method=hash in group flows result in performance degradation when compared to dp_hash ? | 17:40 |
| zhouhan | blp: ok, could you help review the backport patch? | 17:40 |
| *** atpa8a has quit IRC | 17:40 | |
| blp | The VMware team eventually catches up with these things, but they don't necessarily do it quickly, so if there's any particular patch you need then you have to either ask someone politely or do it yourself. | 17:40 |
| zhouhan | blp: I see, thanks. | 17:40 |
| mmichelson | blp, who would a good "someone" be for these sorts of things? | 17:40 |
| blp | Greg | 17:41 |
| blp | Greg Rose | 17:41 |
| flaviof | let me drop a link format for that here | 17:42 |
| flaviof | #link https://mail.openvswitch.org/pipermail/ovs-discuss/2020-May/050001.html discussion on dp_hash consistency problem | 17:42 |
| mmichelson | flaviof, thanks! | 17:42 |
| flaviof | is this is too disruptive, lmk and I will not offe it again ;) | 17:42 |
| zhouhan | flaviof: thanks! | 17:42 |
| flaviof | np | 17:42 |
| zhouhan | I noticed another constraint of dp_hash, which is the 64 hash value limit | 17:43 |
| *** atpa8a has joined #openvswitch | 17:43 | |
| blp | zhouhan: It looks like only dp_hash uses recirculation. I think that method=hash is going to send a lot of packets to userspace, hurting performance. | 17:43 |
| mmichelson | I thought it was 256? | 17:43 |
| zhouhan | So in LB case, if the backend number is high, it automatically fall back to "hash" | 17:43 |
| zhouhan | blp: exactly, that's also my concern. | 17:43 |
| zhouhan | mmichelson: it is 64 and I verified that :) | 17:44 |
| mmichelson | zhouhan, ok I guess I was mistaken | 17:44 |
| zhouhan | In ECMP use case, it may be ok, since usually there won't be so many nexthops. | 17:44 |
| blp | The constnats I see in the source imply 256 bucket max. | 17:44 |
| blp | #define MAX_SELECT_GROUP_HASH_VALUES 256 | 17:45 |
| mmichelson | That's what I was basing my question on, too. | 17:45 |
| zhouhan | I am pretty sure, let me find the code I saw | 17:45 |
| zhouhan | I will send it later, let me continue | 17:46 |
| mmichelson | I'm glad we're having this talk because when my turn comes around, I have more stuff regarding groups and buckets to discuss. | 17:46 |
| numans | ovn-k8s adds a lot of backends to the load balancer. Some times > 64. | 17:46 |
| _lore_ | zhouhan: sorry to jump in, what probe interval are you refering to since after 300s it does not recover yet | 17:46 |
| zhouhan | I found another more problem of dp_hash in ECMP testing, when pinging a LRP's IP. The packet is dropped because of "deferred action limit reached, drop recirc action" | 17:47 |
| zhouhan | This suggests endless recirc in the datapath. I have no idea yet why would this happen. | 17:47 |
| zhouhan | There is datapath flow like: recirc_id(0x1ef492),tunnel(tun_id=0xa0011ff0002,src=10.172.66.12,dst=10.78.211.43,flags(-df+csum+key)),in_port(2),eth(),eth_type(0x0800),ipv4(frag=no), packets:460, bytes:45080, used:6.278s, actions:hash(l4(0)),recirc(0x1ef492) | 17:48 |
| blp | The probe interval is the idle time before a probe is sent. An additional interval is allowed without a reply before disconnecting. If the interval is 180 s then 360 s are required to disconnect. | 17:48 |
| zhouhan | The recirc_id is same between match and action, so it is recirced back to same entry. | 17:49 |
| zhouhan | blp: any suggestion how to debug this? | 17:49 |
| _lore_ | blp: ack, thx | 17:49 |
| blp | zhouhan: My suggestion is always ofproto/trace ;-) | 17:50 |
| *** ktraynor has quit IRC | 17:51 | |
| zhouhan | blp: with dp_hash, if I give the hash input (any value), the trace would should expected actions without dropping anything. | 17:51 |
| zhouhan | blp: without hash provided, it always goes to "no live bucket". I thought there might be some extra tricks needed here to debug. | 17:52 |
| zhouhan | I wonder if it is related to how the value of "dp_hash" is generated by the datapath. | 17:52 |
| zhouhan | maybe we can discuss this offline, if no immediate hint | 17:53 |
| *** timothy has quit IRC | 17:53 | |
| zhouhan | Apart from this, I did some code review, and also some minor patches. | 17:53 |
| zhouhan | One of them is a fix to the manpage generation. #link: https://patchwork.ozlabs.org/project/openvswitch/patch/1588354161-17113-1-git-send-email-hzhou@ovn.org/ | 17:54 |
| blp | Hmm. | 17:54 |
| zhouhan | blp: could you take a look at this small change? Without this the ovn-architecture manpage is not generated properly. | 17:55 |
| numans | zhouhan, thanks for looking into the I-P patches. | 17:55 |
| numans | and dceara too | 17:55 |
| zhouhan | numans: I will continue reviewing this week. | 17:55 |
| numans | thanks. | 17:55 |
| dceara | numans, me too, i just looked at the first patch until now | 17:55 |
| zhouhan | One of the patches I reviewed worth discussing is the multi-localnet ports on same LS. | 17:56 |
| zhouhan | I finally got the whole point after discussion in the review. I think I am fine with the approach, although there might be some modeling incompleteness in OVN by using a single LS to model multiple L2 networks. | 17:57 |
| zhouhan | That's all that I want to report :) | 17:57 |
| numans | I saw the discussion between you and ihrachys. I didn't get the chance to look into the patches yet. | 17:57 |
| numans | I can go real real quick. | 17:57 |
| numans | I reviewed few patches. | 17:58 |
| numans | And I worked on the load balancer selection fields support. Thanks to Han, Mark and Maciej for the reviews. | 17:58 |
| numans | I applied that patch to master. | 17:58 |
| blp | zhouhan: The question in my mind is, why would it recirc to the same bucket? It's very odd. Can you get that out of the trace? | 17:58 |
| numans | I also worked on a small feature to mark a packet from each VIF of the logical port if the mark is set by CMS. | 17:59 |
| numans | #link https://patchwork.ozlabs.org/project/openvswitch/patch/20200501184810.1082602-1-numans@ovn.org/ | 17:59 |
| numans | This feature is required by ovn-k8s. | 17:59 |
| numans | That's it from me. | 17:59 |
| mmichelson | I'll jump in real quick | 17:59 |
| mmichelson | I was working on an issue reported by Girish ages ago where he was attempting to set up a large load balancer. The problem is the GROUP_MOD request sent by ovn-controller exceeded the max size of an openflow message. | 18:00 |
| zhouhan | blp: the trace never showed recirc back to same ID. The trace shows either "no live bucket" and stop, or (if I provide a hash value like dp_hash(0x1/0xf)), it will just finish normally and finally output the packet. | 18:00 |
| zhouhan | blp: or is there anything I missed for how to do the trace in this case? | 18:01 |
| mmichelson | I wrote up a patch to split the request into an ADD, followed by one or more INSERT_BUCKETS commands. This way the entire group can be communicated to ovs-vswitchd | 18:01 |
| mmichelson | This introduces two problems. | 18:02 |
| mmichelson | 1) If you try to run `ovs-ofctl dump-groups br-int` you get an openflow error, presumably because it's attempting to communicate the entire group in a single OF response instead of using multipart. | 18:02 |
| mmichelson | And more importantly 2) There are messages in the ovs-vswitchd log saying that too many hash values are required, so it falls back to "default hash method" from dp_hash | 18:02 |
| *** psahoo has quit IRC | 18:02 | |
| mmichelson | I'm curious about what this "default hash method" is, since it's not documented in the group documentation in ovs-ofctl | 18:03 |
| mmichelson | My assumption is that this means a super slow userspace hashing method, but it's not clear what the hash is based on. | 18:03 |
| *** ryzhyk has quit IRC | 18:03 | |
| numans | mmichelson, I think default hash method is selection_method=hash with no hash fields. | 18:04 |
| numans | #link https://github.com/openvswitch/ovs/blob/master/ofproto/ofproto-dpif-xlate.c#L4553 | 18:04 |
| numans | see this function. | 18:04 |
| numans | I mean no hash fields specified by the controller | 18:05 |
| zhouhan | blp: mmichelson: My bad for the MAX dp_hash values. It is 256 instead of 64. So I guess what I tested was 256. :( | 18:05 |
| mmichelson | numans, I had seen that, but I hadn't followed what method that actually used for hashing. I guess I can dig a little deeper | 18:05 |
| numans | Ok. I think it uses 5-tuple hash. | 18:06 |
| mmichelson | all right | 18:06 |
| mmichelson | OK, I'm about 75% through writing a test for it in the test suite. I'll go ahead and post the patch when I'm done with it. I suspect it won't make 20.06 | 18:07 |
| mmichelson | That's fine though. | 18:07 |
| mmichelson | Speaking of, I haven't seen any responses to my e-mail from Friday about which patches people want reviewed for inclusion in 20.06. | 18:07 |
| numans | mmichelson, I've few patches. I reply to your email. | 18:07 |
| mmichelson | numans, thanks | 18:08 |
| mmichelson | And that's all from me. | 18:08 |
| dceara | I have a short update too | 18:08 |
| dceara | I sent a v5 of the IDL fix for monitor_cond_since when disconnects happen. zhouhan, I don't know how easy it is to scale test this in your scenario but I was wondering if you could try it out as you saw the issue on a lot of nodes | 18:09 |
| dceara | #link https://patchwork.ozlabs.org/project/openvswitch/list/?series=175319 monitor_cond_since fix | 18:09 |
| dceara | zhouhan, also a question, re _lore_'s ovn-scale-test PR, I can merge it but I wasn't sure if you're ok with reworking the ACL/PG parts as a follow up PR | 18:10 |
| dceara | #link https://github.com/ovn-org/ovn-scale-test/pull/193 network_policy PR in ovn-scale-test | 18:11 |
| zhouhan | blp: mmichelson: I take it back. I found what I tested is due to this line: "if (group_setup_dp_hash_table(group, 64))" | 18:11 |
| mmichelson | zhouhan, what a roller coaster ride! | 18:11 |
| dceara | That's it from me, thanks | 18:11 |
| zhouhan | It was hardcoded to 64 when no selection method is specified. So with numan's fix, it should use 256 because dp_hash is specified with the OF1.5 :) | 18:12 |
| zhouhan | dceara: sure, I can take a second look for the PR. | 18:12 |
| zhouhan | dceara: and thanks a lot for the monitor_cond_since fix! I will review it. | 18:13 |
| dceara | zhouhan, np, now I managed to add a test for it too so that should give more confidence | 18:13 |
| zhouhan | dceara: for the testing, I am not sure. We only saw it once, but we will keep watching. | 18:13 |
| dceara | zhouhan, ok, with our scale test setup I see the issue often but just on a few nodes | 18:14 |
| dceara | <10 out of 200 usually | 18:14 |
| zhouhan | dceara: that's good, then it will be easy to verify the fix at least :) | 18:15 |
| dceara | zhouhan, with the fix, we don't hit the bug anymore, just saying :) | 18:15 |
| flaviof | May I go next? | 18:16 |
| flaviof | zhouhan your comment on man page made me recall a modest progress I got working for ovn (with Russell's help): | 18:17 |
| flaviof | #link https://docs.ovn.org/en/latest/ref/index.html OVN readthedocs: reference guide | 18:17 |
| flaviof | That is rebuilt out of a webhook from ovn repo, so it should always be up to date. | 18:17 |
| flaviof | also... | 18:19 |
| flaviof | I noticed a change in behavior for acls. The acls for allow-related action do not conntrack packets to the logical router. | 18:19 |
| numans | flaviof++ | 18:20 |
| zhouhan | flaviof: Actually I checked that one, too :) However it is not up to date. | 18:20 |
| zhouhan | flaviof: maybe it is from a stable branch? | 18:20 |
| flaviof | oh, it should now... the webhook was not working until ~1week ago | 18:21 |
| blp | mmichelson: The default hash method is a symmetric L4 hash. | 18:21 |
| flaviof | did you check after that? | 18:21 |
| zhouhan | The recent change made by blp in ovn-architecture doc is not there. | 18:21 |
| zhouhan | I checked just now :) | 18:21 |
| flaviof | oh, ok. sorry, that part needs to be address still. my bad. | 18:21 |
| flaviof | the webhook does not yet do the "make docs" target. | 18:22 |
| zhouhan | flaviof: ok, I see. | 18:23 |
| flaviof | will work on that next. ;) | 18:23 |
| flaviof | anyways, on the acl behavior subject. | 18:23 |
| flaviof | A few months back, I wrote a little blog covering ovsdbapp as an alternative | 18:24 |
| flaviof | to do what russellb wrote in an old gist with shell commands: | 18:24 |
| flaviof | #link https://gist.github.com/russellb/4ab0a9641f12f8ac66fdd6822ee7789e russellb/ovn-test-icmp-reproducer.sh | 18:24 |
| flaviof | #link https://github.com/flavio-fernandes/ovsdbapp_playground/blob/a9e780ce7ad57215b2200eba14c515482be84d63/scripts/step2_create_logical_ports.py russellb's equivalent in ovsdbapp | 18:24 |
| zhouhan | blp: I think the default for userspace datapath is "symmetric L4 hash", but for kernel datapath it is the hash from skb. | 18:24 |
| flaviof | The acls for allow-related action do not conntrack packets to the logical router. | 18:25 |
| flaviof | In order to make it work, I needed to add new explicit rules: | 18:25 |
| flaviof | #link https://github.com/flavio-fernandes/ovsdbapp_playground/commit/a9e780ce7ad57215b2200eba14c515482be84d63 acl rules changes to make | 18:25 |
| flaviof | Is this a known and expected behavior? No worries if you do not know; just thought of | 18:25 |
| flaviof | bringing it up here in case any of you have made changes in the last month or so that could have changed this behavior. | 18:25 |
| flaviof | that is all. sorry for the overlapp. | 18:25 |
| numans | flaviof, you mean you're not able to ping the router ip unless an ACL is added ? | 18:25 |
| blp | zhouhan: I don't see anything datapath dependent in ofproto-dpif-xlate.c for this. Look at pick_select_group() and pick_default_select_group(). | 18:25 |
| flaviof | numans: no, sorry. I can ping the rtr just fine, using just the 'allow-related' rule. | 18:26 |
| numans | flaviof, ok | 18:26 |
| flaviof | numans: but now it seems that the conntrack logic does not take packets to rtr into account. This may be a fad | 18:27 |
| numans | ok. | 18:27 |
| flaviof | argh... sorry. I _used_ to be able to ping router by having the 'allow-related' rule. Now that is no longer working. | 18:28 |
| numans | flaviof, can you report this in discuss ML so tht we can discuss there ? | 18:28 |
| flaviof | numans: will do. thanks. | 18:28 |
| * numans signs off. | 18:28 | |
| numans | Bye everryone | 18:28 |
| mmichelson | Bye! | 18:28 |
| mmichelson | #endmeeting | 18:28 |
| flaviof | bue all | 18:28 |
| openstack | Meeting ended Thu May 7 18:28:53 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:28 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/ovn_community_development_discussion/2020/ovn_community_development_discussion.2020-05-07-17.16.html | 18:28 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/ovn_community_development_discussion/2020/ovn_community_development_discussion.2020-05-07-17.16.txt | 18:28 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/ovn_community_development_discussion/2020/ovn_community_development_discussion.2020-05-07-17.16.log.html | 18:28 |
| zhouhan | blp: for dp_hash, it should be pick_select_group() -> pick_dp_hash_select_group(), right? | 18:28 |
| zhouhan | and there it triggers ctx_trigger_recirculate_with_hash() | 18:29 |
| dceara | Bye everyone | 18:29 |
| _lore_ | bye all | 18:30 |
| zhouhan | This problem didn't happen at the source HV, where I believe the hash is generated by linux socket. It always happens on gateway nodes, where the packet is received from tunnel | 18:31 |
| zhouhan | blp: ^ | 18:31 |
| zhouhan | Not sure if this is related | 18:31 |
| *** acidfoo has quit IRC | 18:33 | |
| *** acidfoo has joined #openvswitch | 18:34 | |
| zhouhan | blp: Oh I just realized your earlier post about the default is not about dp_hash default. Forgot what I said. It is not relevant :) | 18:36 |
| *** mmirecki has joined #openvswitch | 18:38 | |
| *** aginwala has quit IRC | 18:38 | |
| *** ryzhyk has joined #openvswitch | 18:45 | |
| *** ryzhyk has quit IRC | 18:47 | |
| *** mmirecki has quit IRC | 19:02 | |
| *** SarahStep has joined #openvswitch | 19:08 | |
| *** SarahStep has quit IRC | 19:11 | |
| *** dceara has quit IRC | 19:24 | |
| *** livelace has quit IRC | 19:48 | |
| *** mmirecki has joined #openvswitch | 19:52 | |
| *** dceara has joined #openvswitch | 19:57 | |
| *** dceara has quit IRC | 20:13 | |
| *** mmirecki has quit IRC | 20:23 | |
| *** acidfu_ has joined #openvswitch | 20:29 | |
| *** acidfoo has quit IRC | 20:31 | |
| *** livelace has joined #openvswitch | 20:39 | |
| *** rebrec79 is now known as rebrec | 21:03 | |
| *** ChantalZale has joined #openvswitch | 21:11 | |
| *** ChantalZale has quit IRC | 21:14 | |
| *** livelace has quit IRC | 21:14 | |
| *** ohama has quit IRC | 21:35 | |
| *** ohama has joined #openvswitch | 21:35 | |
| *** blp has left #openvswitch | 21:37 | |
| *** dcbw has quit IRC | 22:01 | |
| *** slaweq has quit IRC | 22:14 | |
| *** duso has quit IRC | 22:15 | |
| *** duso has joined #openvswitch | 22:17 | |
| *** slaweq has joined #openvswitch | 22:20 | |
| *** troulouliou_div2 has quit IRC | 22:24 | |
| *** slaweq has quit IRC | 22:24 | |
| *** bostondriver has quit IRC | 22:56 | |
| *** zhouhan_ has joined #openvswitch | 23:21 | |
| *** zhouhan has quit IRC | 23:25 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!