TCP LRO: add dtrace probe points

[tuexen]

Summary

Add the IP, UDP, and TCP receive static probes for the code path, which avoids if_input.

[markj]

sys/netinet/tcp_lro_hpts.c

283

These lines are too long and should be wrapped.

307

Is this case possible? If not, it should contain a __assert_unreachable();.

[tuexen]

Address Marks comments.

[markj]

sys/netinet/tcp_lro_hpts.c

316

Why do you not pass lc->ifp here?

[tuexen]

sys/netinet/tcp_lro_hpts.c

316

Please note that this is right now unreachable code, since at the beginning of _tcp_lro_flush_tcphpts ensures that le->inner.data.lro_type == LRO_TYPE_NONE holds. But the code after that, does not restrict itself to it.

For testing I removed the condition at the beginning of _tcp_lro_flush_tcphpts and tested using

vxlan0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1450
	options=80020<JUMBO_MTU,LINKSTATE>
	ether 58:9c:fc:00:f3:35
	inet 10.0.1.86 netmask 0xffffff00 broadcast 10.0.1.255
	groups: vxlan
	vxlan vni 108 local 192.168.1.86:4789 remote 192.168.1.87:4789
	media: Ethernet autoselect (autoselect <full-duplex>)
	status: active
	nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

with

mce0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
	options=ffef07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,NV,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,TXRTLMT,HWRXTSTMP,MEXTPG,TXTLS4,TXTLS6,VXLAN_HWCSUM,VXLAN_HWTSO,TXTLS_RTLMT,RXTLS4,RXTLS6>
	ether 98:03:9b:7d:2d:da
	inet 192.168.1.86 netmask 0xffffff00 broadcast 192.168.1.255
	media: Ethernet 10GBase-CR1 <full-duplex,rxpause,txpause>
	status: active
	nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

The Connectx-4 card supports the parsing of the inner and outer headers. In this case the outer header is the IP/UDP header with mce0 as the interface, the inner header would be the IP/TCP header with vxlan0 as the interface.
Now using ipio.d gives:

10                             192.168.1.86 <- 192.168.1.87                                  mce0     82
 4                                10.0.1.86 <- 10.0.1.87                                <unknown>     32
30                                10.0.1.86 -> 10.0.1.87                                   vxlan0    756
 7                             192.168.1.86 -> 192.168.1.87                                  mce0    806

If I would use lc->ifp, the <unknown> interface would be shown as mce0, where it should be vxlan0. In my view this is the best I can do.
We can provide the wrong parameter and hope that once this code path is officially supported will be updated (assuming that the correct interface pointer is available at that time). But I prefer to be defensive and report it now as unknown.

[markj]

IMO it is worth documenting this scenario in dtrace_ip.4.