On 05/20/2016 09:35 AM, Jonathan Morton wrote:
On 20 May, 2016, at 19:20, Rick Jones <rick.jon...@hpe.com> wrote:
I suppose if said software were to dive below the socket interface
it could find-out, though that will tend to lack portability.
I’m a little fuzzy on UDP socket semantics.
Could the sender set DF on a small proportion of the packets, and
listen for ICMP errors to the effect? These packets could also be
salted with distinguishable data so that the receiver can tell
whether the DF packets, in particular, got through.
The Linux manapge for UDP asserts:
By default, Linux UDP does path MTU (Maximum Transmission Unit) discov‐
ery. This means the kernel will keep track of the MTU to a specific
target IP address and return EMSGSIZE when a UDP packet write exceeds
it. When this happens, the application should decrease the packet
size. Path MTU discovery can be also turned off using the IP_MTU_DIS‐
COVER socket option or the /proc/sys/net/ipv4/ip_no_pmtu_disc file; see
ip(7) for details. When turned off, UDP will fragment outgoing UDP
packets that exceed the interface MTU. However, disabling it is not
recommended for performance and reliability reasons.
But I haven't seen that EMSGSIZE happen with netperf UDP tests - could
be though I've never run them in an environment which triggered PTMUD.
I don't have visibility into the assertions for *BSD and other Unices.
I'm thinking that modulo not knowing with certainty it was the only
thing sending and/or receiving traffic, sampling IP stats about
fragments before the test and again after would be a more
straightforward way to check instead of complicating the benchmark's
data path.
happy benchmarking,
rick jones
_______________________________________________
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake
