Maybe better solution is just provide 64-bit counters for all interfaces? It seems net-snmpd does so.

In D15112#318277, @bz wrote:

Other question: why do we not set baudrate on the virtual interfaces?

Can you provide some numbers what benefits you have with this patch?

Maybe it would be enough to just introduce new IFNET_EVENT_PCP type for ifnet_event?

Looks good to me.

This looks good to me.

Also, both setsockopt() have the check

if (!error)
         INP_WUNLOCK(in6p);

but both getsockopt() have not it.

Why you need INP_WLOCK() for getsockopt()? Also ipsec_get_pcbpolicy() requieres INP_WLOCK(), and IPv4 version uses WLOCK, but IPv6 version uses RLOCK.

In D14385#301995, @olivier wrote:

Ready to do a bench: Does "our patches" means is this review or another patch ?

In D14385#301537, @mjoras wrote:

You can't just state it has "significant performance penalties" by looking at the code. Consider also that the path if_output takes isn't as direct as you might think anyway. When a vlan's if_output gets called you end up back in ether_output_frame. That ends up calling the interface's if_transmit, which puts you back in vlan_transmit. So the old path would have been:

In D12685#301251, @will wrote:

I admit I haven't looked at this very carefully, but: how do these dynamic states get freed? From dyn_expire_states:
To my untrained (and quickly reviewing) eye, it looks like these lists get cleared only in ipfw_dyn_uninit, here:

How it supposed to work for RADIX_MPATH case? I know RADIX_MPATH is currently broken, but anyway...

Invoking of rt_updatemtu() looks right to me. But I don't like how rt_updatemtu() works.
Recently we found that in6_mtutimo() on systems with many IPv6 routes produces noticeable delay for packets processing.
It holds RIB_WLOCK while all routes are processed, and thus normal packets processing is blocked on RIB_RLOCK for this time.
Also in6_mtutimo looks like dead code, that is doing nothing useful.

It would be good have some progress with this review.

The description looks confusing to me. As I understand, the problem is that fib6_lookup_nh_basic() returns next hop address without embedded scope zone id, so when it is IPv6 link-local address, the IN6_ARE_ADDR_EQUAL() comparison will fail due to src6 has this zone id embedded in.

I'll try to change the related code to use ck_pr_xxx_32 operations, it seems all platforms support them.

I tried to build universe and it is failed to build on sparc64 and powerpc. At least not all CK's primitives are defined for these platforms.

In D13715#296744, @kristof wrote:

I'd like to fix the issue where pf can't reliably figure out if it should call ip6_forward() or ip6_output(). I'd like to do so without negatively affecting the general forwarding performance (with or without pf).