From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 23:01:59 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9BA61065670; Wed, 4 Jan 2012 23:01:58 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 142E58FC1F; Wed, 4 Jan 2012 23:01:57 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so21155898obb.13 for ; Wed, 04 Jan 2012 15:01:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7FnC6DjnzHaYHGN3a9vewKqdNZylj+Q4DiHE657GST8=; b=oJpwDDL5qv8AGoUjvj8aDMcupq9yDl6ozjMkNfs8YfU4n/FIkx4gfz/cz5UXjbnbEJ zKwlS6hHzYP/YtciSMxbaRQQ7vMrTzl5xypuYwWdGtvr2+vQ9EAywVgXRcaJzVwXsJ01 vDKpLBwUp8LzZOH6e5NBVMFfQ9UNXA6bN870M= MIME-Version: 1.0 Received: by 10.182.78.165 with SMTP id c5mr49880719obx.60.1325718117399; Wed, 04 Jan 2012 15:01:57 -0800 (PST) Received: by 10.182.67.163 with HTTP; Wed, 4 Jan 2012 15:01:57 -0800 (PST) In-Reply-To: References: <0A9B7C39-DFA9-4C65-BE39-CC72E18DAB87@mac.com> <52A4B11E-592E-458D-BA0F-9B5A349F4B73@mac.com> <1E97A7DF-71C3-4F3A-A24F-017CF5DC8E4F@mac.com> Date: Wed, 4 Jan 2012 15:01:57 -0800 Message-ID: From: Xin LI To: Dan The Man Content-Type: text/plain; charset=UTF-8 Cc: Robert Watson , Gleb Smirnoff , Arnaud Lacombe , freebsd-current@freebsd.org Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 23:02:00 -0000 Hi, On Wed, Jan 4, 2012 at 2:50 PM, Dan The Man wrote: [...] > How about a sensible solution? I think everyone has been making valid points > here, about sensible limits for all programs on system and per application > limit changes. > > How about changing the hard limit high, and an application can make the soft > limit higher as it sees fit, its a win win, like ulimit does with openfiles > and such. Looking at the code, it seems that there is no reason we can't make this u_short be u_int and just change the limit to U_INTMAX. The biggest problem that one would hit here is that changes the binary interface of both struct xsocket and struct socket consumers. Cheers, -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die