Hi Ben, Thanks for taking a look, and for your comments in Gerrit.
Our main use case is diagnosing ECMP path issues. Different TCP connections between the same endpoints can take different paths because their ports contribute to the hash. If one path is faulty, some TCP connections can fail while ICMP Echo probes keep taking a healthy path, making the problem harder to diagnose. Including the Echo identifier would let us vary it to sample different ECMP paths with ICMP, while keeping the IP endpoints fixed and each probe session stable. This is useful even when ICMP is only a small fraction of the traffic. I agree that we should avoid adding overhead to the default TCP/UDP path. Our repeated Ice Lake/GCC 14.3 microbenchmarks still show small increases in hash time, with run-to-run variation; we have not measured end-to-end VPP throughput and cannot claim that the default path is unaffected. Your suggestion of a separately configurable hash function makes sense. I propose reworking this as an opt-in ICMP-Echo-aware hash function, keeping the existing implementation as the default. The goal would be to keep the additional ICMP processing out of the default path. I would benchmark both the default and opt-in paths against the unpatched baseline before posting a revised patch. Agreed on keeping the explicit if/else structure for readability; I will not pursue the nested ternary variant. Thanks, Timur
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#27215): https://lists.fd.io/g/vpp-dev/message/27215 Mute This Topic: https://lists.fd.io/mt/121467998/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
