Re: discrepancy in ip(7) wrt. IP DF flag for UDP sockets

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux