On Wed, 31 Oct 2012, Jozsef Kadlecsik wrote: > 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. It seems to me, the best is to add a stripped down version of "getaddrinfo" to ipset itself. That'll be the first library workaround... 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
