fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
<ciupicri>
can systemtap be used to trace what iptables is doing and how long it takes?
<fche>
hi ciupicri
<fche>
a couple of possibilities
<fche>
first, stap can itself hook into the netfilter processing chain, and be as though it were an iptables-like module, and can observe traffic before or after the other modules
<fche>
second, stap could probe iptable module internals, monitor their function calls, that sort of thing
<fche>
functions -within modules-. Anything compiled into the core kernel would show up as kernel.function("*").call (not-inlined)
<ciupicri>
CONFIG_NETFILTER=y, CONFIG_NETFILTER_ADVANCED=y so it looks like they're in the core indeed
<ciupicri>
I've found this: kernel.function("ip_packet_match@net/ipv4/netfilter/ip_tables.c:47") , but running para-callgraph.stp 'kernel.function("ip_packet_match@net/ipv4/netfilter/ip_tables.c")' fails with "semantic error: while resolving probe point: identifier 'kernel' at"
<fche>
the rest of the message probably helps explain
<fche>
here it says ... "WARNING: cannot probe .return of 1 inlined functions ip_packet_match"
<ciupicri>
I see it too
<ciupicri>
so I have to find another function that isn't inlined
<fche>
yeah. or not use para-callgraph
<fche>
if you just probe kernel.function("ip_packet_match") { println($$parms) } you should get something for inlined fns too
<ciupicri>
you mean it's possible to analyze even inlined functions?
<fche>
yes, and statements within them
<ciupicri>
ip=0xffff951ea88c404e ip=0xffff951ea88c404e ip=0xffff951ea88c404e isfrag=0x0 ... I'm seeing ip multiple times because stap is smart enough to figure out the length of the ip array and print all of it?
<fche>
nope, I suspect it's an inlining artifact :)
<fche>
if you want it pretty-printed, try println($ip$)