Devel

devel@lists.kronosnet.org

1 participants
49 discussions

by Fabio M. Di Nitto

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

7 years, 1 month

[HA Summit 2017] follow up on questions after knet upstream presentation

by Fabio M. Di Nitto

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

7 years, 2 months

Why two github repositories?

by Michael Jones

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?

7 years, 3 months

to SCTP or not to SCTP?

by Fabio M. Di Nitto

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

8 years, 6 months

corosync + knet fixes (summary from IRC)

by Fabio M. Di Nitto

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

8 years, 6 months

Re: [fabbione/kronosnet] 1705d7: [send/recv] add simplistic packet re-assembly code

by Digimer

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?

9 years, 1 month

Potential init.d script

by Digimer

I adapted the smbd init.d script. It contains some assumptions, so please review it. Cheers -- Digimer E-Mail: digimer(a)alteeve.com AN!Whitepapers: http://alteeve.com Node Assassin: http://nodeassassin.org

14 years

Initial tutorial

by Digimer

I want to first write a "tutorial" style document for Kronosnet, and then I will create the "man" page style and complete option list doc. I'd like to stick with wiki format for now, as I am most used to it, and then push it into publican when it's more complete. http://wiki.alteeve.com/index.php/Kronosnet Please provide feedback. I made some (semi-educated) assumptions which may be quite wrong. Cheers! -- Digimer E-Mail: digimer(a)alteeve.com AN!Whitepapers: http://alteeve.com Node Assassin: http://nodeassassin.org

14 years

Mailing list test

by Federico Simoncelli

Hi, this is a test. -- Federico

14 years, 2 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Devel