From owner-freebsd-net Wed Aug 2 20:54:31 2000 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 0D32837B6EA for ; Wed, 2 Aug 2000 20:54:24 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id XAA21343; Wed, 2 Aug 2000 23:54:06 -0400 (EDT) (envelope-from wollman) Date: Wed, 2 Aug 2000 23:54:06 -0400 (EDT) From: Garrett Wollman Message-Id: <200008030354.XAA21343@khavrinen.lcs.mit.edu> To: jayanth Cc: freebsd-net@FreeBSD.ORG Subject: Max data queued for UDP In-Reply-To: <20000802111412.A29943@yahoo-inc.com> References: <20000802111412.A29943@yahoo-inc.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < 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