Devel

devel@lists.kronosnet.org

53 discussions

PMTUd remaining issues
by Fabio M. Di Nitto 10 Dec '17

10 Dec '17

Hey Chrissie, I am still having issues with the latest pmtu code: 1) using crypto, just with knet_bench ping_data test, the MTU changes on each run (I think you mentioned that on IRC, but not sure it's the same problem). 2) there is a spurious link down event on MTU change. I can reproduce this one without crypto and with ping_data test (I set it at 10 secs interval to avoid waiting minutes). Start knet_bench on both nodes with standard MTU at 1500. At the end of each run, change MTU on the interfaces to: - 1400 (good). - 1500 (good). - 1600 (good, mtu doesn't change) - back to 1500 (link down event) from time to time, the first MTU after the down/up event is wrong the code is stable on heavy load, I haven't tested yet load + changing MTU at runtime. I'll do that once the basic tests are passing. Cheers Fabio

2 1

0.9 RC - merge freeze
by Fabio M. Di Nitto 05 Dec '17

05 Dec '17

Hi guys, we have one PR open (plugins/modules) and one bug fix (PMTUd) pending. We will complete the merge of both and we will not accept any more changes for 0.9 RC. Between 0.9 and 1.0 we will only accept critical bug fixes. Any other change is 2.0/1.1 material. Cheers Fabio

3 2

plugin future (after 1.0)
by Fabio M. Di Nitto 05 Dec '17

05 Dec '17

Hey Feri, what do you think for a 1.1 or 2.0 feature: https://trello.com/c/nJLaEOMw/735-consider-to-develop-a-more-dynamic-plugin… Also, if you have a trello account, I'd be happy to add you there to better track who is working on what. Cheers Fabio

1 0

Re: [kronosnet/kronosnet] a2f08e: Switch over all plugins to the module system
by Fabio M. Di Nitto 01 Dec '17

01 Dec '17

Hey Feri, let me stop you a minute here. what is the end goal of this work? We originally didn´t implement the modules model because it has several downsides for little benefit, based on the experience we had with corosync modules in the past. I think it might be beneficial to have a chat about those major changes before you implement them :-) I *hate* for people to waste time on stuff that might not merge. Cheers Fabio On 11/28/2017 8:07 AM, GitHub wrote: > Branch: refs/heads/modules > Home: https://github.com/kronosnet/kronosnet > Commit: a2f08e189c0143381f9f3ac5031d6b5dd32f5432 > https://github.com/kronosnet/kronosnet/commit/a2f08e189c0143381f9f3ac5031d6… > Author: Ferenc Wágner <wferi(a)debian.org> > Date: 2017-11-28 (Tue, 28 Nov 2017) >

4 18

kronosnet v0.8 (aka 1.0 Beta) released
by Fabio M. Di Nitto 27 Oct '17

27 Oct '17

All, We are pleased to announce the first public beta of kronosnet v1.0 - which we are calling v0.8 (to make distro packager life a bit easier :-)) kronosnet (or knet for short) is the new underlying network protocol for Linux HA components (corosync), that features ability to use multiple links between nodes, active/active and active/passive link failover policies, automatic link recovery, FIPS compliant encryption (nss and/or openssl), automatic PMTUd and in general better performances compared to the old network protocol. The source tarballs can be downloaded here: http://www.kronosnet.org/releases/ Upstream resources and contacts: http://www.kronosnet.org/ https://github.com/kronosnet/kronosnet/ https://ci.kronosnet.org/ https://trello.com/kronosnet (TODO list and activities tracking) https://goo.gl/9ZvkLS (google shared drive with presentations and diagrams) IRC: #kronosnet on Freenode http://lists.kronosnet.org/mailman/listinfo/users http://lists.kronosnet.org/mailman/listinfo/devel http://lists.kronosnet.org/mailman/listinfo/commits Known issues in this release: * FreeBSD port currently does not work https://trello.com/c/fJSU31Fa/122-fix-port-to-freebsd * Missing developer documentation / best practice and .3 man pages https://trello.com/c/HxL2JIFI/32-add-documentation https://trello.com/c/d5nk9rLS/30-add-3-man-pages Cheers, The knet developer team

1 0

[HA Summit 2017] follow up on questions after knet upstream presentation
by Fabio M. Di Nitto 23 Sep '17

23 Sep '17

Hey guys, as $subject, the only pending question that I was not able to answer directly during the presentation was: "why are knet is not using vxlan encapsulation?" Tl;dr: the vxlan and knet don't share the same use cases and vxlan is not completely fit for the HA use case. I spent some time looking at vxlan and wrote a small doc: https://docs.google.com/document/d/1fmMiIPYg01s1d8WbnKC51x2DvaBCKQB9g6p8gAp… please feel free to comment in the doc. Thanks Fabio

1 1

Why two github repositories?
by Michael Jones 22 Sep '17

22 Sep '17

On Github.com, searching for "kronosnet" turns up two repositories: https://github.com/kronosnet/kronosnet and https://github.com/fabbione/kronosnet Which is the correct repository? Why have two? Can one be decommissioned?

3 5

to SCTP or not to SCTP?
by Fabio M. Di Nitto 03 Jun '16

03 Jun '16

All, i have been playing around with SCTP as transport for knet for a while now, as a possibility to pipe DLM traffic via knet. The PoC patch is working fine, but the performances vs UDP are rather discouraging (at least using CPG bench), with SCTP being able to handle just a bit more than 50% of UDP performances. Before I invest too much time into it, the question become: do we really care for a potential knet 1.0? My take here is to either postpone or drop SCTP for now and re-evaluate for 2.0. Idea here is being also able to make it easier to plugin different network protocols. Right now the code is very much designed around one single network protocol and the patch is very invasive in some areas with little flexibility (meaning having to break API/ABI every time we add a new protocol). My suggestion would be to refactor the network code to be more modular and after we have a more dynamic/better designed API/ABI, we can add N protocols without suffering too much. agree? disagree? Fabio

2 1

corosync + knet fixes (summary from IRC)
by Fabio M. Di Nitto 03 Jun '16

03 Jun '16

Hey Chrissie, i found the bugs in totemknet that made knet so slow and now I am getting up to 50% more cpgbench performance (19MB/sec on 64 bytes pckts) vs udpu (13MB/sec). First bug is the dst_host_filter. this is not your fault, your thinking was sound but it didn't do the right thing. We need to fix the knet API doc and possibly I can also fix the code to be smarter. The issue is that for RX packet, you make an exception where if we are sending pckts to self, you return that the pckt is unicast. This is confusing the packet deduplicator because it will try to match mcast pckts against unicast seq num. The dst_host_filter shouldn't change unicast/mcast, but return data from the pckt. In theory this can be simplified because those information are already inside the onwire packet. I'll review that soon enough because it's confusing and incorrect. Anyway to unblock testing: +#if 0 if (tx_rx == KNET_NOTIFY_RX) { dst_host_ids[0] = this_host_id; *dst_host_ids_entries = 1; res = 0; /* already home */ } else { +#endif and remove the stray } ;) Second is the MTU calculation that's generating unnecessary fragmented pckts. extern void totemknet_net_mtu_adjust (void *knet_context, struct totem_config *totem_config) { - fprintf(stderr, "MTU = %d\n", totem_config->net_mtu); - totem_config->net_mtu = 1444; + // fabbione: need to export libknet header size from libknet somehow + totem_config->net_mtu -= totemip_udpip_header_size(AF_INET) + 23; } This calculation is correct for AF_INET interfaces (we need to fix it for IPv6 and such but it's a start. This also unveiled a less important bug in knet that doesn't export all MTU information to applications, but it doesn't affect corosync directly (that hard coded 23 should be an API call). Using the combination of those 2 gives me a 14 to 15 MB/sec on 64 bytes packets in cpgbench using default netmtu of 1500. The last boost is netmtu changes. Bumping netmtu in corosync.conf to 4096 I get to 19MB/sec. Now there is a bug in corosync netmtu somewhere. I didn't bother to investigate because it's sunday, I tried 8192 and corosync started to misbehave, as if it's not sending pckts till buffer is full (or that's the feeling I got). Bumping netmtu to 64000 makes corosync hang. So there is definitely some work to be done to fix it and most likely get better performances out of the system. Cheers Fabio

2 4

Re: [fabbione/kronosnet] 1705d7: [send/recv] add simplistic packet re-assembly code
by Digimer 24 Oct '15

24 Oct '15

On 24/10/15 01:24 AM, GitHub wrote: > Branch: refs/heads/master > Home: https://github.com/fabbione/kronosnet > Commit: 1705d7e083348329aba3d7c90c992500207e9113 > https://github.com/fabbione/kronosnet/commit/1705d7e083348329aba3d7c90c9925… > Author: Fabio M. Di Nitto <fdinitto(a)redhat.com> > Date: 2015-10-24 (Sat, 24 Oct 2015) > > Changed paths: > M libknet/internals.h > M libknet/threads_send_recv.c > > Log Message: > ----------- > [send/recv] add simplistic packet re-assembly code > > this will probably explode if you are using multiple links > in round-robin or active-active mode. > > Signed-off-by: Fabio M. Di Nitto <fdinitto(a)redhat.com> DEVICE="fun0" BONDING_OPTS="mode=0" ifup fun0 **my god, it's full of stars...** -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Devel