HI Ben, Neil, On Thu, Sep 22, 2011 at 2:44 PM, Benjamin Poirier <benjamin.poirier@xxxxxxxxx> wrote: > On 11-09-22 06:15, Michael Kerrisk wrote: >> Ben, Neil, >> > [snip] >> >> Ben, thanks for writing this, and Neil, thanks for reviewing it. I've >> applied that change for man-pages-3.34. >> >> Ben, I added one small piece ti the description of >> /proc/sys/net/ipv4/ip_no_pmtu_disc. For completeness, I've reproduced >> the entire text below. Perhaps you could take a quick scan, to make >> sure that the changed text is consistent with the whole piece. >> >> Thanks, >> >> Michael >> >> IP_MTU_DISCOVER (since Linux 2.2) >> Set or receive the Path MTU Discovery setting for a >> socket. When enabled, Linux will perform Path MTU Dis- >> covery as defined in RFC 1191 on SOCK_STREAM sockets. > > Oops, seems like there's a repetition that crept in here. I'd keep only > the first of those two sentences: >> For non-SOCK_STREAM sockets, IP_PMTUDISC_DO forces the >> don't-fragment flag to be set on all outgoing packets. >> The don't-fragment flag is set on all outgoing data- >> grams. Thanks for catching that! The second of the above sentences is now gone. >> It is the user's responsibility to packetize the >> data in MTU-sized chunks and to do the retransmits if >> necessary. The kernel will reject (with EMSGSIZE) data- >> grams that are bigger than the known path MTU. >> IP_PMTUDISC_WANT will fragment a datagram if needed >> according to the path MTU, or will set the don't-frag- >> ment flag otherwise. >> >> The system-wide default can be toggled between IP_PMTUD- >> ISC_WANT and IP_PMTUDISC_DONT by writing (respectively, >> zero and nonzero values) to the >> /proc/sys/net/ipv4/ip_no_pmtu_disc file. > > I think it's a welcome clarification. Is is normal that IP_PMTUDISC_WANT > gets hyphenated? That's just an artifact of groff formatting. One can prevent it, but then the text justification of some lines starts to look very weird. >> Path MTU discovery flags Meaning > > I agree with what Neil said about "flags" here. setsockopt(2) calls > these "option values". Changed this to just "value". > Other than that, LGTM > Acked-by: Benjamin Poirier <benjamin.poirier@xxxxxxxxx> > > Thanks Michael, > -Ben You're welcome. Thanks for taking the time to write the text and check my work. Cheers, Michael >> IP_PMTUDISC_WANT Use per-route settings. >> IP_PMTUDISC_DONT Never do Path MTU Discovery. >> IP_PMTUDISC_DO Always do Path MTU Discovery. >> IP_PMTUDISC_PROBE Set DF but ignore Path MTU. >> >> When PMTU discovery is enabled, the kernel automatically >> keeps track of the path MTU per destination host. When >> it is connected to a specific peer with connect(2), the >> currently known path MTU can be retrieved conveniently >> using the IP_MTU socket option (e.g., after an EMSGSIZE >> error occurred). The path MTU may change over time. >> For connectionless sockets with many destinations, the >> new MTU for a given destination can also be accessed >> using the error queue (see IP_RECVERR). A new error >> will be queued for every incoming MTU update. >> >> While MTU discovery is in progress, initial packets from >> datagram sockets may be dropped. Applications using UDP >> should be aware of this and not take it into account for >> their packet retransmit strategy. >> >> To bootstrap the path MTU discovery process on uncon- >> nected sockets, it is possible to start with a big data- >> gram size (up to 64K-headers bytes long) and let it >> shrink by updates of the path MTU. >> >> To get an initial estimate of the path MTU, connect a >> datagram socket to the destination address using con- >> nect(2) and retrieve the MTU by calling getsockopt(2) >> with the IP_MTU option. >> >> It is possible to implement RFC 4821 MTU probing with >> SOCK_DGRAM or SOCK_RAW sockets by setting a value of >> IP_PMTUDISC_PROBE (available since Linux 2.6.22). This >> is also particularly useful for diagnostic tools such as >> tracepath(8) that wish to deliberately send probe pack- >> ets larger than the observed Path MTU. >> >> >> -- >> Michael Kerrisk >> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ >> Author of "The Linux Programming Interface"; http://man7.org/tlpi/ > -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of "The Linux Programming Interface"; http://man7.org/tlpi/ -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
