Dear Team, can we address at least #1112, #1119 before 2.4 is released ?
пт, 9 апр. 2021 г. в 20:52, Willy Tarreau <w...@1wt.eu>: > Hi, > > HAProxy 2.4-dev16 was released on 2021/04/09. It added 37 new commits > after version 2.4-dev15. > > This one is particularly calm, I even hesitated between making it or not. > But there are a few updates that may affect configuration so I figured it > was better to emit a new one. > > A large part of the patch is essentially caused by the renaming of a few > atomic ops that were causing some confusion. Now HA_ATOMIC_FOO() will be > a void statement so that if you want to read from the location you use > either HA_ATOMIC_FETCH_FOO() or HA_ATOMIC_FOO_FETCH() (pre- or post- > fetch). The output code shouldn't change however, and given that it was > essentially sed-work, as soon as it started to work I was confident in it. > > A few changes in the FD code to clean up that messy fdtab structure cause > another noticeable part of the diff. I obviously managed to break > something once (hence the BUG/MAJOR fix) but now it's OK. Mistakes at this > level are never forgiving anyway, either it fully works or it fully fails. > > The nice part that makes me think we're progressively approaching what > could look like the release is that Emeric finally performed the few > changes in the DNS and log code. For the DNS, the TCP servers in the > "resolvers" section do not need to be referred to as "server" anymore, > they are "nameserver" just like the other ones, except that you can > mention "tcp@" in front of their address to force them to be TCP > nameservers. No more configuration mixing there. And for the log servers, > similarly, now you can specify "tcp@" in front of an address on a "log" > statement, and it will automatically create the ring for you with default > settings. Previously it was still required to manually declare the ring, I > found this too cumbersome, and Emeric figured how to handle this. > > The rest is essentially small bug fixes and code cleanups from a bunch > of contributors. > > Now speaking about the pending stuff I'm still aware of: > > - I'd like to rename LIST_ADD/LIST_ADDQ to LIST_INSERT/LIST_APPEND > (or maybe LIST_ADD_HEAD/LIST_ADD_TAIL ?). I've already been trapped > in using LIST_ADD() when I wanted to append and I know the confusion > is easy. That's just a quick "sed" once we know what we want. > > - I identified some undesired cache line sharing around some pointers, > that slow down FD operations and possibly other stuff. I see how to > arrange this, it just needs to be done (and tested on MacOS since we > noticed once that section names differ there). > > - we've had a recent discussion about the opportunity to import SLZ > and to always enable compression by default using it if no other lib > is specified. I think it could be useful for some users (especially > those for whom memory usage is important). I'll have a look at this, > maybe next week, that's only two files to include. > > - regarding the quick discussion two weeks ago about optimization for > modern ARM CPUs, I saw that one solution could be to build using > gcc 10.2+ which outline their atomics into functions. That's ugly > but the performance impact is small (about 3% in my tests), while > it provides a tremendous improvement for many-core machines. But if > we rely on this do this I'll probably add two new CPU entries to > force to use only an old one (v8.0) or only a modern one (v8.2) so > that those who build themselves can shave the last few percent. > > - no progress made on the default-path, but we'll have to reread the > issue to figure the best choice. I'd like to see it done for the > release to ease config packaging and deployments. > > - I'd like to add a warning when we detect that nbthreads is forced > to a higher value than the number of bound CPUs. It's not the first > time that I see this in a config and the result is catastrophic, so > a warning is deserved. It just needs to be set at the right place. > > - the shared memory pools cleanup must be completed before the release, > as the situation is not good for those with a slow malloc() function > at the moment. I know what to do, I just need to stay focused on it. > > - the date & time cleanups would be nice to have for the long term and > are not particularly hard to do so better finish them before 2.4. > > - Tim sent a patch series to implement URI normalization. That's > something > I'd like to see merged if possible, as it may improve security for some > users, and at least improve reliability for others. > > - I also noticed Alek's mjson import with a new converter, but didn't > have a look yet. Maybe it will open opportunities for more converters, > that's definitely something which deserves being considered before the > release. > > - Amaury has almost finished some work to improve auto-binding on NUMA > systems. Right now using a dual-socket machine is common an painful at > the same time. Having threads enabled by default doesn't improve the > situation there at all due to the slow communication between the CPUs. > In his tests he could confirm significant gains by binding only to the > CPUs of a single socket by default if nothing is specified. I'd like > to see this merged as well. It also opens opportunities for refining > later if needed. > > - Christopher has some pending fixes for abortonclose that we'd rather > merge early to observe any possibly undesired side effect. > > - I had an idea to experiment with regarding the ability to close idle > frontend connections on reload. It should be relatively easy to do > and could solve a long-lasting problem those with long connections > suffer from. If done in time and if it works well, maybe we could > even consider backporting it. > > - and I still would like to add a few macros for the .if/.endif in the > config file, but that's not critical. > > As long as we can continue with fixes and low-risk stuff like this, I > think we'll be good for the initial plans of end of May. If we complete > all of this earlier, I'm even fine with anticipating the release a little > bit (but I doubt it). > > So far, so good. Have a happy week-end, and don't forget to test and report > your concerns or any improvement you'd notice. > > Please find the usual URLs below : > Site index : http://www.haproxy.org/ > Discourse : http://discourse.haproxy.org/ > Slack channel : https://slack.haproxy.org/ > Issue tracker : https://github.com/haproxy/haproxy/issues > Wiki : https://github.com/haproxy/wiki/wiki > Sources : http://www.haproxy.org/download/2.4/src/ > Git repository : http://git.haproxy.org/git/haproxy.git/ > Git Web browsing : http://git.haproxy.org/?p=haproxy.git > Changelog : http://www.haproxy.org/download/2.4/src/CHANGELOG > Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/ > > Willy > --- > Complete changelog : > Christopher Faulet (3): > MINOR: No longer rely on deprecated sample fetches for predefined > ACLs > MINOR: acl: Add HTTP_2.0 predefined macro > BUG/MINOR: hlua: Detect end of request when reading data for an HTTP > applet > > Emeric Brun (5): > MINOR: server/bind: add support of new prefixes for addresses. > MINOR: log: register config file and line number on log servers. > MEDIUM: log: support tcp or stream addresses on log lines. > BUG/MEDIUM: log: fix config parse error logging on stdout/stderr or > any raw fd > MEDIUM: resolvers: add support of tcp address on nameserver line. > > Miroslav Zagorac (1): > MINOR: opentracing: register config file and line number on log > servers > > Thayne McCombs (1): > BUG/MINOR: tools: fix parsing "us" unit for timers > > Tim Duesterhus (7): > MINOR: ist: Add `istappend(struct ist, char)` > MINOR: ist: Add `istshift(struct ist*)` > MINOR: ist: Add `istsplit(struct ist*, char)` > MINOR: ist: Rename istappend() to __istappend() > CLEANUP: htx: Make http_get_stline take a `const struct` > CLEANUP: ist: Remove unused `count` argument from `ist2str*` > CLEANUP: Remove useless malloc() casts > > Willy Tarreau (20): > CLEANUP: dev/flags: remove useless test in the stdin number parser > CLEANUP: fd: remove FD_POLL_DATA and FD_POLL_STICKY > MEDIUM: fd: prepare FD_POLL_* to move to bits 8-15 > MEDIUM: fd: merge fdtab[].ev and state for FD_EV_* and FD_POLL_* > into state > MINOR: fd: move .linger_risk into fdtab[].state > MINOR: fd: move .cloned into fdtab[].state > MINOR: fd: move .initialized into fdtab[].state > MINOR: fd: move .et_possible into fdtab[].state > MINOR: fd: move .exported into fdtab[].state > MINOR: fd: implement an exclusive syscall bit to remove the ugly > "log" lock > MINOR: cli/show-fd: slightly reorganize the FD status flags > MINOR: atomic/arm64: detect and use builtins for the double-word CAS > CLEANUP: atomic: add an explicit _FETCH variant for add/sub/and/or > CLEANUP: atomic: make all standard add/or/and/sub operations return > void > CLEANUP: atomic: add a fetch-and-xxx variant for common operations > CLEANUP: atomic: add HA_ATOMIC_INC/DEC for unit increments > CLEANUP: atomic/tree-wide: replace single increments/decrements with > inc/dec > CLEANUP: atomic: use the __atomic variant of BTS/BTR on modern > compilers > MINOR: atomic: implement native BTS/BTR for x86 > BUG/MAJOR: fd: switch temp values to uint in fd_stop_both() > > --- > >
