Re: [ANNOUNCE] keepalived 2.0.1
Quentin Armitage <[email protected]> Fri, 15 Jun 2018 18:19:35 +0100
| Newsgroups | gmane.linux.keepalived.devel |
|---|---|
| Organization | The Armitage family |
| Message-ID | <[email protected]> |
--===============4296803038940762121== Content-Type: multipart/alternative; boundary="=-cj6RMf0A+rRUtje+WiX9" --=-cj6RMf0A+rRUtje+WiX9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit On Fri, 2018-06-15 at 17:44 +0200, Patrick Schaaf wrote: > On Fri, Jun 15, 2018 at 4:20 PM, Quentin Armitage > <[email protected]> wrote: > > At the moment keepalived uses select() for sending and receiving on > > sockets, > > and keepalived opens two sockets per interface that it is using for > > vrrp > > (one send, one receive). When using VMACs that means two sockets > > per vrrp > > instance, and since select() has a limit of 1024 file descriptors, > > I vaguely remember that in the past (> 10 years ago) it was possible > to put the select calls into their own compilation unit (.c -> .o) > and > there, before #including any of the usual socket stuff, #define > FD_SETSIZE or something like that to a larger value, to make select > support more than 1024 descriptors - the limit basically having been > a > userlevel one for the fd_set definitions from the headers, not a > kernel side one. Might have changed meanwhile, though, but I thought > I'd mention it :) > Patrick, Many thanks for this info, which I didn't know about. My only concern about using this is that the man page for select() states: > BUGS > POSIX allows an implementation to define an upper limit, > advertised via the constant FD_SETSIZE, on the range of > file descriptors that can be specified in a file descriptor > set. The Linux kernel imposes no fixed limit, but the > glibc implementation makes fd_set a fixed-size type, with > FD_SETSIZE defined as 1024, and the FD_*() macros operat‐ > ing according to that limit. To monitor file descriptors > greater than 1023, use poll(2) instead. I think although it may work, it would be a risky thing to do. I have tried the following little test: > #define __FD_SETSIZE 2048 > #define FD_SETSIZE 2048 > > #include <sys/select.h> > > int main(int argc, char **argv) > { > fd_set q; > > FD_ZERO(&q); > FD_SET(1280, &q); > } If this is compiled with -D_FORTIFY_SOURCE=1 -O gcc options, then when it runs it aborts due to 1280 >= 1024. Quentin --=-cj6RMf0A+rRUtje+WiX9 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable <html><head></head><body bgcolor=3D"#ffffff" text=3D"#2e3436" link=3D"#2a76= c6" vlink=3D"#2e3436"><div>On Fri, 2018-06-15 at 17:44 +0200, Patrick Schaa= f wrote:</div><blockquote type=3D"cite" style=3D"margin:0 0 0 .8ex; border-= left:2px #729fcf solid;padding-left:1ex"><pre>On Fri, Jun 15, 2018 at 4:20 = PM, Quentin Armitage <<a href=3D"mailto:[email protected]">[email protected]</a>&= gt; wrote: <blockquote type=3D"cite" style=3D"margin:0 0 0 .8ex; border-left:2px #729f= cf solid;padding-left:1ex"> At the moment keepalived uses select() for sending and receiving on sockets= , and keepalived opens two sockets per interface that it is using for vrrp (one send, one receive). When using VMACs that means two sockets per vrrp instance, and since select() has a limit of 1024 file descriptors, </blockquote> I vaguely remember that in the past (> 10 years ago) it was possible to put the select calls into their own compilation unit (.c -> .o) and there, before #including any of the usual socket stuff, #define FD_SETSIZE or something like that to a larger value, to make select support more than 1024 descriptors - the limit basically having been a userlevel one for the fd_set definitions from the headers, not a kernel side one. Might have changed meanwhile, though, but I thought I'd mention it :) </pre></blockquote><div>Patrick,</div><div><br></div><div>Many thanks for t= his info, which I didn't know about. My only concern about using this is th= at the man page for select() states:</div><blockquote type=3D"cite" style= =3D"margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div= >BUGS</div><div> POSIX = allows an implementation to define an upper limit, ad= vertised via the constant FD_SETSIZE, on the range of</div><div>  = ; file descriptors that can be specified in a = file descriptor set. The Linux kernel imposes no fixed limit, bu= t the</div><div> glibc = implementation makes fd_set a fixed-size type, with FD_SETSIZE defined as 1= 024, and the FD_*() macros operat=E2=80=90</div><div> &nbs= p; ing according to that limit. To monitor file= descriptors greater than 1023, use poll(2) instead.</div></blockquote><div= ><br></div><div>I think although it may work, it would be a risky thing to = do.</div><div><br></div><div>I have tried the following little test:</div><= blockquote type=3D"cite" style=3D"margin:0 0 0 .8ex; border-left:2px #729fc= f solid;padding-left:1ex"><div>#define __FD_SETSIZE 2048</div><div>#define = FD_SETSIZE 2048</div><div><br></div><div>#include <sys/select.h></div= ><div><br></div><div>int main(int argc, char **argv)</div><div>{</div><div>= fd_set q;</div><div><br></div><div> FD_ZERO(&q);</div><div> FD_SET(128= 0, &q);</div><div>}</div></blockquote><div><br></div><div>If this is co= mpiled with -D_FORTIFY_SOURCE=3D1 -O gcc options, then when it runs it abor= ts due to 1280 >=3D 1024.</div><div><br></div><div>Quentin</div></body><= /html> --=-cj6RMf0A+rRUtje+WiX9-- --===============4296803038940762121== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot --===============4296803038940762121== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Keepalived-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/keepalived-devel --===============4296803038940762121==--