Hi, walk_remove_by_peer does seem inefficient. Judging by the stack, I guess it walks the tree looking for addresses from a specific peer. That would be roughly O(A log A) operations for A addresses, in total O(N A log A) if removing all of them.
A simple fix would be to know what you want to remove. Then you can find it fast in the search tree. Does showing peer configuration also scan the entire tree? If you need to store a list of addresses associated with a peer (seems like a good idea), memory needed should be no more and probably less than the tree itself. I can explain an algorithm, or tell you how to fix it, but I'm not saying I will code it (yet). WRT setconf/addconf/syncconf >From a user point of view, I do not see a reason to disconnect peers which are not modified when changing confguration. It seems excessive and not quite useful. After reading wg man page [1], I do have questions about what these commands do. 1) When setconf-ing an interface without optional parameters, and the interface was configured with a non-default values, do they remain or are they reset to defaults? I guess either would be fine as long as it is consistent. Both interface and peer configuration. a) Listen port - if not specified, I would leave as is. It has already been chosen (perhaps) randomly. 2) If a peer is connected and the configured endpoint changes, does the endpoint change? Does the peer get disconnected? If a peer has roamed, you edit another peer and run setconf, it doesn't seems nice to disconnect the roaming peers. OTOH, if you want change the address (e.g. to a another valid one), it would be nice if the peers moved to the new addresses in a reasonable time. 3) Regarding addconf - after reading the man page, I'm not sure what the intent is, or what does it do. a) It says only one interface section can be in a file, is changing the interface configuration permitted? If not, it should probably be called addpeers. b) Are multiple definitions of the same peer permitted? If so, what is the result - can I split the definitions, or are the previous ones discarded? What about ips, are they summed or overriden? Regards, Ivan [1] https://git.zx2c4.com/WireGuard/about/src/tools/man/wg.8 On 14. 6. 2019 20:09, Jason A. Donenfeld wrote: > Hey Lonnie, > > If your changes are user-facing, it's probably not a good idea to > create confusion by introducing distro-specific subcommands. > > I'm leaning toward Steven's suggestion of nixing addconf and making > setconf behave like syncconf. But two hurdles remain: > > - walk_remove_by_peer is very inefficient. That *must* be to be > improved for this to be feasible. There's some interesting algorithms > programming in allowedips.c to be tackled for that. Maybe > node->peer_list can be used. (CC'ing Ivan in case he wants to put his > mind to work on that.) > - A decision needs to be made on consistency: do we want to read back > the end result and compare it? Or will that kind of looping logic lead > to other types of DoS or latency spikes? > > Jason > _______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard