Date: Wed, 2 Aug 2000 23:54:06 -0400 (EDT) From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> To: jayanth <jayanth@yahoo-inc.com> Cc: freebsd-net@FreeBSD.ORG Subject: Max data queued for UDP Message-ID: <200008030354.XAA21343@khavrinen.lcs.mit.edu> In-Reply-To: <20000802111412.A29943@yahoo-inc.com> References: <20000802111412.A29943@yahoo-inc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
<<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.) 3) There was a third thing, but it's escaping me at this late hour. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick 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?200008030354.XAA21343>