On Wed, 31 Oct 2012, Jan Engelhardt wrote: > On Wednesday 2012-10-31 17:27, Josh Hunt wrote: > > > When doing an ipset restore with newer versions of glibc I'm seeing > > some extra syscall overhead that I was not seeing with glibc 2.4. I > > was wondering if anyone has seen such behavior and could help me > > understand what is going on? > > > > Here is a snippet of strace during the restore with glibc 2.4: > > http://pastebin.com/qxkPF7FB and one with glibc 2.7: > > http://pastebin.com/wga9SN0E > > I've also seen similar behavior with glibc 2.11. > > > > You'll notice that with the newer version a second netlink socket is created > > and it appears some data is sent and info received back from the kernel > > I have observed such as well in other programs as well. Without > looking into this too deeply, I suspect that a program, or a library > on its behalf, is using the interface name<->index resolution > functions if_nametoindex(3) et al, for which netlink is used in > sufficiently new glibc where socket ioctls were (probably) used > previously. Could this be it? ipset does not check interface names (except the length of the string), so does not call if_nametoindex. The extra syscalls come from "getaddrinfo", which is used by ipset to parse every IP address. In eglibc 2.11 the implementation of "getaddrinfo" contains the comment and the uncoditional call: /* We might need information about what interfaces are available. Also determine whether we have IPv4 or IPv6 interfaces or both. We cannot cache the results since new interfaces could be added at any time. */ __check_pf (&seen_ipv4, &seen_ipv6, &in6ai, &in6ailen); And indeed, __check_pf opens up a netlink socket, makes a request then closes it. I haven't checked the source code of glibc itself but I suppose it works the same way. Best regards, Jozsef - E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxxxxxx PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
