Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 Mar 2001 09:15:49 -0800
From:      Lars Eggert <larse@ISI.EDU>
To:        David Malone <dwmalone@maths.tcd.ie>
Cc:        freebsd-net@freebsd.org
Subject:   Re: UDP datagram max size.
Message-ID:  <3AAFA745.AA3EC6B6@isi.edu>
References:  <200103141703.aa78458@salmon.maths.tcd.ie>

next in thread | previous in thread | raw e-mail | index | archive | help

[-- Attachment #1 --]
David Malone wrote:
> 
> I'm trying to figure out what #define I should use for the largest
> UDP datagram. The header files don't seem to define a constant for
> this. The correct size would seem to be 65535 'cos there are two
> bytes in the UDP header for the size.
> 
> IP_MAXPACKET and IPV6_MAXPACKET are available and have the right
> values, but these don't really seem to be the correct thing to use
> 'cos they don't take headers or the possibility Jumbo payload into
> account.

To support jumbograms, I don't think you'll get around dynamic memory
allocation. (There is no reasonable upper bound for the buffer size.)

However, RFC2675 says:

   The Jumbo Payload option is relevant only for IPv6 nodes that may be
   attached to links with a link MTU greater than 65,575 octets (that
   is, 65,535 + 40, where 40 octets is the size of the IPv6 header).
   The Jumbo Payload option need not be implemented or understood by
   IPv6 nodes that do not support attachment to links with MTU greater
   than 65,575.

So it may be okay to punt on jumbograms for now, and use a 64K static
buffer like the patch in the PR does. Even if you do implement support for
jumbograms, I think keeping the 64K static buffer around as a "fast-path"
for the common case makes sense.

> I wanted to commit something for:
> 
>         http://www.FreeBSD.org/cgi/query-pr.cgi?pr=25050
> 
> but I'm not convinced that the patch is spot on. I could determine
> the data size and malloc memory dynamically I guess.

-- 
Lars Eggert <larse@isi.edu>                 Information Sciences Institute
http://www.isi.edu/larse/                University of Southern California
[-- Attachment #2 --]
0#	*H
010	+0	*H
00A#0
	*H
010	UZA10UWestern Cape10UDurbanville10
U
Thawte10UCertificate Services1(0&UPersonal Freemail RSA 1999.9.160
000824203008Z
010824203008Z0T10
UEggert1
0U*Lars10ULars Eggert10	*H
	
larse@isi.edu00
	*H
0\p9޻ H;v֐r∩6"C?mxfJf7I[3CF́L	I
-zHRVA怤2]0-bL)%X>nӅw0u0*+e!000L2uMyffBNUbNJJcdZ2s0U0
larse@isi.edu0U00U#0`fUXFa#Ì0
	*H
_3	F=%nWY-HXD9UOc6ܰwf@uܶNԄR?Pr}E1֮23mFhySwM_h|d yR=$P 00}0
	*H
010	UZA10UWestern Cape10U	Cape Town10U
Thawte Consulting1(0&UCertification Services Division1$0"UThawte Personal Freemail CA1+0)	*H
	personal-freemail@thawte.com0
990916140140Z
010915140140Z010	UZA10UWestern Cape10UDurbanville10
U
Thawte10UCertificate Services1(0&UPersonal Freemail RSA 1999.9.1600
	*H
0iZz]!#rLK~r$BRW{azr98e^eyvL>hput,O	1ArƦ]D.Mօ>lx~@эWs0FO7050U00U#0rIs4Uvr~wƲ0
	*H
kY1rr`HU{gapm¥7؝(V\uoƑlfq|ko!6-	-mƃRt\~
orzg,ksnΝc)	~U100010	UZA10UWestern Cape10UDurbanville10
U
Thawte10UCertificate Services1(0&UPersonal Freemail RSA 1999.9.16#0	+0	*H
	1	*H
0	*H
	1
010314171549Z0#	*H
	1rf{E$N0R	*H
	1E0C0
*H
0*H
0+0
*H
@0
*H
(0
	*H
bo븒^kHsIo9OG
ScHCEZ}-[EQ7*leQWxF|۟(̻.vmP8E߄~ŷ̰8KSLT]

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3AAFA745.AA3EC6B6>