Date: Thu, 3 Aug 2000 13:36:40 -0700 From: jayanth <jayanth@yahoo-inc.com> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: freebsd-net@FreeBSD.ORG Subject: Re: Max data queued for UDP Message-ID: <20000803133640.B23963@yahoo-inc.com> In-Reply-To: <200008030354.XAA21343@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Wed, Aug 02, 2000 at 11:54:06PM -0400 References: <20000802111412.A29943@yahoo-inc.com> <200008030354.XAA21343@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Garrett Wollman (wollman@khavrinen.lcs.mit.edu) wrote: > <<On Wed, 2 Aug 2000 11:14:12 -0700, jayanth <jayanth@yahoo-inc.com> said: > > > So for very small udp packets the total > > no. of packets that can be queued is > > sb_mbmax / (cluster + mbuf) = 256K / (2048 + 256) = 113 packets. > > This is a well-known feature of the BSD stack. The purpose is to > limit the amount of wired-down kernel memory an unprivileged (or even > remote) user can cause to be a allocated. A cluster is always > allocated by most drivers because those drivers are trying to optimize > for speed, and this interferes destructively with the flow-control > policy in the socket buffer layer. > > Any allocation or compression policy of this kind will have a ``sour > spot'' where packet sizes tip over into the next-size bucket. > Finer-grained allocation is a bad idea, since it would require copying > many packets -- and that in turn opens up DoS opportunities. > > There are a few things which would help: > > 1) Push the socket buffering down into the protocol. This would allow > protocols to override the socket buffer flow-control policy with one > actually appropriate to the protocol. (Van Jacobson has been flaming > about this for a decade or more.) For PR_ATOMIC protocols, a > flow-control policy which I think has merit is to use a RED queue, and > allow the user to specify the x1 and x2 values. For TCP, the right > flow-control policy is to use TCP's flow-control. > > 2) In m_pullup(), automatically copy the entire packet out of the > cluster if it would fit, and free the cluster. This will cost some, > but I think it's a win because the IP stack will call m_pullup almost > immediately upon receiving a packet, we're already committed to doing > a copy, and the current implementation of m_pullup will then allocate > an extra mbuf. (This would bite for multicast routing, however. The > way to fix that is to keep m_pullup out of the multicast routing code > path.) In the m_pullup() case, for two consecutive tcp packets with data that fits into one mbuf , will the second packet will be copied twice , once during m_pullup() and once during sbcompress() ? jayanth ~ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000803133640.B23963>