From owner-freebsd-net@FreeBSD.ORG Sun Aug 4 08:50:01 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B5D276C1 for ; Sun, 4 Aug 2013 08:50:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A174622B4 for ; Sun, 4 Aug 2013 08:50:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r748o1dK098824 for ; Sun, 4 Aug 2013 08:50:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r748o1Em098823; Sun, 4 Aug 2013 08:50:01 GMT (envelope-from gnats) Date: Sun, 4 Aug 2013 08:50:01 GMT Message-Id: <201308040850.r748o1Em098823@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Joao Neves Cabral Subject: Re: kern/181006: [run] [patch] mbuf leak in run(4) driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Joao Neves Cabral List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 08:50:01 -0000 The following reply was made to PR kern/181006; it has been noted by GNATS. From: Joao Neves Cabral To: bug-followup@FreeBSD.org, jcnc@dhis.org Cc: Subject: Re: kern/181006: [run] [patch] mbuf leak in run(4) driver Date: Sun, 4 Aug 2013 09:49:19 +0100 Sorry, just a couple of mistakes/corrections: 1. Where it reads "netstat -nr" should read "netstat -m". 2. It might not be an alignment problem at all, but just a display/check = problem in the driver. --- But the patch seems to have fixed the issue and the network hasn't = hanged since and the mbufs are now stable:=20 jcnc@witch ~]$ netstat -m 2/268/270 mbufs in use (current/cache/total) 2/132/134/31744 mbuf clusters in use (current/cache/total/max) 2/126 mbuf+clusters out of packet secondary zone in use (current/cache) 1/8/9/15872 4k (page size) jumbo clusters in use = (current/cache/total/max) 0/0/0/4702 9k jumbo clusters in use (current/cache/total/max) 0/0/0/2645 16k jumbo clusters in use (current/cache/total/max) 8K/363K/371K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/4/4608 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines From owner-freebsd-net@FreeBSD.ORG Sun Aug 4 19:05:12 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B8567D70 for ; Sun, 4 Aug 2013 19:05:12 +0000 (UTC) (envelope-from rpaulo@FreeBSD.org) Received: from felyko.com (felyko.com [IPv6:2607:f2f8:a528::3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id A284A246B for ; Sun, 4 Aug 2013 19:05:12 +0000 (UTC) Received: from [IPv6:2601:9:4d00:119:c1a4:5299:ada4:3d28] (unknown [IPv6:2601:9:4d00:119:c1a4:5299:ada4:3d28]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 6A42B3981E; Sun, 4 Aug 2013 12:05:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Adding an address to a downed LAGG interface breaks it? From: Rui Paulo In-Reply-To: <1A778AD3F807B340B7EB1BD1B9C196773D655FE6@zenyatta.int.panasas.com> Date: Sun, 4 Aug 2013 12:05:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1A778AD3F807B340B7EB1BD1B9C196773D655FE6@zenyatta.int.panasas.com> To: "Newpol, Richard" X-Mailer: Apple Mail (2.1508) Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 19:05:12 -0000 On 1 Aug 2013, at 09:22, "Newpol, Richard" wrote: > All, > We seem to have discovered a problem that occurs when adding an = address (or alias) to a DOWNed lagg interface. After adding an address, = when you try to bring the interface UP it can't reach the desired = networks. >=20 > Turns out that the problem occurs because the lagg driver silently = passes the SIOCSIFADDR ioctl to the "ether_ioctl" handler, which in turn = always sets the IFF_UP flag. >=20 > While this is usually ok (since ifconfig
implies UP = with the first assigned address anyway), the lagg driver does not have = the proper handling to actually change state to UP on the first address, = so it ends up in an inconsistent state. Then, when the user eventually = does an "ifconfig lagg up" the default subnet routes are not added = (because the "interface up" code sees that IFF_UP is already set). >=20 > So my first question - is this a known problem, or has it been = addressed in some other way? >=20 > Secondly, I can think of two ways to fix this, and was wondering what = are the implications. The first way would be for the lagg driver to = correctly bring itself up when the first address is added to it. The = second way would be for the lagg driver to preserve the state of = IFF_FLAG when handling SIOCSIFADDR. I like the second way because it is = less of an overall behaviour change from the current, but the first way = seems more correct. After you add the first address, you said it comes to an inconsistent = state. Can you clarify? The first approach seems like the right fix but I don't know much about = the problem. The second way breaks the POLA because you're special = casing lagg just to work around a bug. -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Sun Aug 4 19:13:11 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7C69BAA for ; Sun, 4 Aug 2013 19:13:11 +0000 (UTC) (envelope-from rmind@netbsd.org) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6B26224E0 for ; Sun, 4 Aug 2013 19:13:11 +0000 (UTC) Received: from ws (localhost [IPv6:::1]) by mail.netbsd.org (Postfix) with SMTP id 2FFBB14A152; Sun, 4 Aug 2013 19:13:10 +0000 (UTC) Date: Sun, 4 Aug 2013 20:12:49 +0100 From: Mindaugas Rasiukevicius To: tech-net@netbsd.org, freebsd-net@freebsd.org Subject: BPF_MISC+BPF_COP and BPF_COPX X-Mailer: mail(1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20130804191310.2FFBB14A152@mail.netbsd.org> Cc: guy@alum.mit.edu X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 19:13:11 -0000 Hello, I would like propose new BPF instructions for the misc category: BPF_COP and BPF_COPX. It would provide a capability of calling an external function - think of BPF "coprocessor". The argument for BPF_COP is an index to a pre-loaded array of function pointers. BPF_COPX takes the function index from the register X rather than a constant. BPF_STMT(BPF_MISC+BPF_COP, 0), /* A <- funcs[0](...) */ typedef uint32_t(*bpf_copfunc_t)(struct mbuf *pkt, uint32_t A, uint32_t *M); int bpf_set_cop(bpf_ctx_t *c, bpf_copfunc_t funcs[], size_t n); The arguments passed to a called function would be the packet, accumulator and the memory store. The return value would be stored in the accumulator and the register X would be reset to 0. Note that the function may also change the memory store. If the function index is out of range, then the register X would be set to 0xffffffff. Note that bpf_filter(9) would need to take some context structure (which is preferable in general). Comments? -- Mindaugas From owner-freebsd-net@FreeBSD.ORG Sun Aug 4 19:31:40 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6D406881 for ; Sun, 4 Aug 2013 19:31:40 +0000 (UTC) (envelope-from rpaulo@felyko.com) Received: from felyko.com (felyko.com [IPv6:2607:f2f8:a528::3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id 53DDE25D0 for ; Sun, 4 Aug 2013 19:31:40 +0000 (UTC) Received: from [IPv6:2601:9:4d00:119:c1a4:5299:ada4:3d28] (unknown [IPv6:2601:9:4d00:119:c1a4:5299:ada4:3d28]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id C3B6B3981E; Sun, 4 Aug 2013 12:31:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=felyko.com; s=mail; t=1375644700; bh=QcO4qCyOiz/o6WYVPnWUUac2366/ohoBLgjrhKnw7NA=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=ca2my3TGdNU1gbTcBPuEehayW3e3glo5zn3WpqDjL7elehkjbXr44MyFL7l4u7EpZ Za7wgHfsfE4A0qzodBthE5XhUylE3H2/RutdnQsfxplbxQwSwJhgjGPuGwuPFcYo5O pEO0uSLX9wLBXvZPmYkR53bie+jui5GeLevBLSMg= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: BPF_MISC+BPF_COP and BPF_COPX From: Rui Paulo In-Reply-To: <20130804191310.2FFBB14A152@mail.netbsd.org> Date: Sun, 4 Aug 2013 12:31:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9813E50B-C557-4FE1-BADF-A2CFFCBB8BD7@felyko.com> References: <20130804191310.2FFBB14A152@mail.netbsd.org> To: Mindaugas Rasiukevicius X-Mailer: Apple Mail (2.1508) Cc: tech-net@netbsd.org, guy@alum.mit.edu, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 19:31:40 -0000 On 4 Aug 2013, at 12:12, Mindaugas Rasiukevicius = wrote: > Hello, >=20 > I would like propose new BPF instructions for the misc category: = BPF_COP > and BPF_COPX. It would provide a capability of calling an external > function - think of BPF "coprocessor". The argument for BPF_COP is an > index to a pre-loaded array of function pointers. BPF_COPX takes the > function index from the register X rather than a constant. >=20 > BPF_STMT(BPF_MISC+BPF_COP, 0), /* A <- funcs[0](...) */ >=20 > typedef uint32_t(*bpf_copfunc_t)(struct mbuf *pkt, > uint32_t A, uint32_t *M); >=20 > int bpf_set_cop(bpf_ctx_t *c, bpf_copfunc_t funcs[], size_t n); >=20 > The arguments passed to a called function would be the packet, = accumulator > and the memory store. The return value would be stored in the = accumulator > and the register X would be reset to 0. Note that the function may = also > change the memory store. If the function index is out of range, then = the > register X would be set to 0xffffffff. >=20 > Note that bpf_filter(9) would need to take some context structure = (which is > preferable in general). >=20 > Comments? Why do you need this in the first place?=20 Are you sure this is a safe design? Adding this functionality to BPF = makes me a little nervous as an error in the implementation leads to = kernel code execution (I could be able to call random kernel functions). -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Sun Aug 4 19:55:40 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BA9129AE for ; Sun, 4 Aug 2013 19:55:40 +0000 (UTC) (envelope-from rmind@netbsd.org) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A70A92762 for ; Sun, 4 Aug 2013 19:55:40 +0000 (UTC) Received: from ws (localhost [IPv6:::1]) by mail.netbsd.org (Postfix) with SMTP id C87A614A135; Sun, 4 Aug 2013 19:55:38 +0000 (UTC) Date: Sun, 4 Aug 2013 20:55:18 +0100 From: Mindaugas Rasiukevicius To: Rui Paulo Subject: Re: BPF_MISC+BPF_COP and BPF_COPX In-Reply-To: <9813E50B-C557-4FE1-BADF-A2CFFCBB8BD7@felyko.com> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <9813E50B-C557-4FE1-BADF-A2CFFCBB8BD7@felyko.com> X-Mailer: mail(1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20130804195538.C87A614A135@mail.netbsd.org> Cc: tech-net@netbsd.org, guy@alum.mit.edu, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 19:55:40 -0000 Rui Paulo wrote: > > > > Comments? > > > Why do you need this in the first place? It provides us a capability to offload more complex packet processing. My primary user would be NPF in NetBSD, e.g. one of the operations is to lookup an IP address in a table/ipset. > Are you sure this is a safe design? Adding this functionality to BPF > makes me a little nervous as an error in the implementation leads to > kernel code execution (I could be able to call random kernel functions). This is functionality is for a custom use of BPF. There would be no coprocessor by default and the instruction would essentially be a NOP. Perhaps I was not clear on bpf_set_cop(9) - it is a kernel routine, so the user would be a kernel subsystem which has a full control over the functions it provides. The functions are predetermined, not random. -- Mindaugas From owner-freebsd-net@FreeBSD.ORG Sun Aug 4 22:30:38 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D6D4DE32 for ; Sun, 4 Aug 2013 22:30:38 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6D5232C3A for ; Sun, 4 Aug 2013 22:30:38 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id k13so1867925wgh.1 for ; Sun, 04 Aug 2013 15:30:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=EQzlBbkX9eJmnudVUSkuvkLlAHPipQTXeeP3Iy6vozg=; b=o6TuXBrCqWboo0SmruJnQWgMPObCBPKqMyvTs26936ApI9/+bgLGDG7EgYD4O8XKH0 KRM20LjM5VajTjXWpKxNwfQGVhCc1r+PVwATlAFh+3qwZjVqJJ36lI43iS437ZlkZla4 gOujvUB1KVgHJVkTjwZGuYvfzPXK5zh+Pf0UEvQVh4kjWr7e9F/HOx6TpORARY6RqkX9 nvI5ZSSgI63dPlGSbLTaOdjxwam2pM61TdHCO95p3O17q0ZgAV/1DBE4msczvBYCJVUM i3BsxzdHM5whhlhd/gYRugRiz8p5PgJbM+4otzlO5NhZ0wa8qbAdfaLQ+D4x/nXmm4hG /eUQ== MIME-Version: 1.0 X-Received: by 10.180.20.116 with SMTP id m20mr4760198wie.46.1375655436584; Sun, 04 Aug 2013 15:30:36 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Sun, 4 Aug 2013 15:30:36 -0700 (PDT) In-Reply-To: <20130804195538.C87A614A135@mail.netbsd.org> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <9813E50B-C557-4FE1-BADF-A2CFFCBB8BD7@felyko.com> <20130804195538.C87A614A135@mail.netbsd.org> Date: Sun, 4 Aug 2013 15:30:36 -0700 X-Google-Sender-Auth: vcMAWwfZm2Np_FbRDKET2_vl4yQ Message-ID: Subject: Re: BPF_MISC+BPF_COP and BPF_COPX From: Adrian Chadd To: Mindaugas Rasiukevicius Content-Type: text/plain; charset=ISO-8859-1 Cc: tech-net@netbsd.org, guy@alum.mit.edu, Rui Paulo , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 22:30:38 -0000 I think it's slightly unfair to propose a new extension for BPF without any in-tree users. Is this going to be some external commercial coprocessor? -adrian On 4 August 2013 12:55, Mindaugas Rasiukevicius wrote: > Rui Paulo wrote: >> > >> > Comments? >> >> >> Why do you need this in the first place? > > It provides us a capability to offload more complex packet processing. > My primary user would be NPF in NetBSD, e.g. one of the operations is to > lookup an IP address in a table/ipset. > >> Are you sure this is a safe design? Adding this functionality to BPF >> makes me a little nervous as an error in the implementation leads to >> kernel code execution (I could be able to call random kernel functions). > > This is functionality is for a custom use of BPF. There would be no > coprocessor by default and the instruction would essentially be a NOP. > Perhaps I was not clear on bpf_set_cop(9) - it is a kernel routine, so > the user would be a kernel subsystem which has a full control over the > functions it provides. The functions are predetermined, not random. > > -- > Mindaugas > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun Aug 4 22:54:36 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2A476335; Sun, 4 Aug 2013 22:54:36 +0000 (UTC) (envelope-from rmind@netbsd.org) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 15F2D2D0E; Sun, 4 Aug 2013 22:54:36 +0000 (UTC) Received: from ws (localhost [IPv6:::1]) by mail.netbsd.org (Postfix) with SMTP id 87A9C14A152; Sun, 4 Aug 2013 22:54:34 +0000 (UTC) Date: Sun, 4 Aug 2013 23:54:12 +0100 From: Mindaugas Rasiukevicius To: Adrian Chadd Subject: Re: BPF_MISC+BPF_COP and BPF_COPX In-Reply-To: References: <20130804191310.2FFBB14A152@mail.netbsd.org> <9813E50B-C557-4FE1-BADF-A2CFFCBB8BD7@felyko.com> <20130804195538.C87A614A135@mail.netbsd.org> X-Mailer: mail(1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20130804225434.87A9C14A152@mail.netbsd.org> Cc: tech-net@netbsd.org, guy@alum.mit.edu, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 22:54:36 -0000 Adrian Chadd wrote: > I think it's slightly unfair to propose a new extension for BPF > without any in-tree users. > We have in-tree user in NetBSD as mentioned in the previous email: > > It provides us a capability to offload more complex packet processing. > > My primary user would be NPF in NetBSD, e.g. one of the operations is to > > lookup an IP address in a table/ipset. I would like to coordinate the reservation of BPF opcodes though. -- Mindaugas From owner-freebsd-net@FreeBSD.ORG Mon Aug 5 00:11:41 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 71813361 for ; Mon, 5 Aug 2013 00:11:41 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 055F62F53 for ; Mon, 5 Aug 2013 00:11:40 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id l18so832289wgh.0 for ; Sun, 04 Aug 2013 17:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=pF1D5C9cOR+S3xlxVc9tPRrrW4boIYa9ueDQouE6C3I=; b=w0l0zWL220tlnlVQuQR3SIq6C0cc4C/dWyS1Yg1STqKffoWeW4PNyvE3uaQ7ZULyZf ej0B2iasnNQ+pFalIFokngNYWX742864evz57/UkCh7wce+OuZ5MpISMVQYEG94ySI/r F1b3s01447IiwHkPplSx1v5v9K4sfXvk3ttkH3/GntcYyRYyv17LISGPrL6X4/9LReXm nDqUy+97b5b5Slo8rouuJcJFfQ84Eze4BgXT+4rBoXy9YNFuFU2IpaHT+3DIrchx9z0t vqvt20S/OzosirUuj73jbPnqaBSNuiFbJVCbzdNgD3Boy1bbC4fee/LrPtqMCwEUEWZm MZUg== MIME-Version: 1.0 X-Received: by 10.180.20.116 with SMTP id m20mr4908543wie.46.1375661498566; Sun, 04 Aug 2013 17:11:38 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Sun, 4 Aug 2013 17:11:38 -0700 (PDT) In-Reply-To: <20130804225434.87A9C14A152@mail.netbsd.org> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <9813E50B-C557-4FE1-BADF-A2CFFCBB8BD7@felyko.com> <20130804195538.C87A614A135@mail.netbsd.org> <20130804225434.87A9C14A152@mail.netbsd.org> Date: Sun, 4 Aug 2013 17:11:38 -0700 X-Google-Sender-Auth: 9poCcNEJ7YAvXmM-15APhHEuEos Message-ID: Subject: Re: BPF_MISC+BPF_COP and BPF_COPX From: Adrian Chadd To: Mindaugas Rasiukevicius Content-Type: text/plain; charset=ISO-8859-1 Cc: tech-net@netbsd.org, guy@alum.mit.edu, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 00:11:41 -0000 On 4 August 2013 15:54, Mindaugas Rasiukevicius wrote: > Adrian Chadd wrote: >> I think it's slightly unfair to propose a new extension for BPF >> without any in-tree users. >> > > We have in-tree user in NetBSD as mentioned in the previous email: Ah, cool. I missed that. >> > It provides us a capability to offload more complex packet processing. >> > My primary user would be NPF in NetBSD, e.g. one of the operations is to >> > lookup an IP address in a table/ipset. > > I would like to coordinate the reservation of BPF opcodes though. That's a good idea. I have no problem with that. -adrian From owner-freebsd-net@FreeBSD.ORG Mon Aug 5 05:20:13 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8E5E3973 for ; Mon, 5 Aug 2013 05:20:13 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5086F28C9 for ; Mon, 5 Aug 2013 05:20:12 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1V6DD9-0002Ui-Gr for freebsd-net@freebsd.org; Mon, 05 Aug 2013 07:20:03 +0200 Received: from rebar.astron.com ([38.117.134.202]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 05 Aug 2013 07:20:03 +0200 Received: from christos by rebar.astron.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 05 Aug 2013 07:20:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: christos@astron.com (Christos Zoulas) Subject: Re: BPF_MISC+BPF_COP and BPF_COPX Date: Mon, 5 Aug 2013 04:36:59 +0000 (UTC) Lines: 32 Message-ID: References: <20130804191310.2FFBB14A152@mail.netbsd.org> <9813E50B-C557-4FE1-BADF-A2CFFCBB8BD7@felyko.com> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: rebar.astron.com X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Cc: tech-net@netbsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 05:20:13 -0000 In article <9813E50B-C557-4FE1-BADF-A2CFFCBB8BD7@felyko.com>, Rui Paulo wrote: >On 4 Aug 2013, at 12:12, Mindaugas Rasiukevicius wrote: > >> Hello, >> >> I would like propose new BPF instructions for the misc category: BPF_COP >> and BPF_COPX. It would provide a capability of calling an external >> function - think of BPF "coprocessor". The argument for BPF_COP is an >> index to a pre-loaded array of function pointers. BPF_COPX takes the >> function index from the register X rather than a constant. >> >> BPF_STMT(BPF_MISC+BPF_COP, 0), /* A <- funcs[0](...) */ >> >> typedef uint32_t(*bpf_copfunc_t)(struct mbuf *pkt, >> uint32_t A, uint32_t *M); >> >> int bpf_set_cop(bpf_ctx_t *c, bpf_copfunc_t funcs[], size_t n); >> >> The arguments passed to a called function would be the packet, accumulator >> and the memory store. The return value would be stored in the accumulator >> and the register X would be reset to 0. Note that the function may also >> change the memory store. If the function index is out of range, then the >> register X would be set to 0xffffffff. Well, aside from the consideration that somehow bpf needs to understand what memory locations the coproc function alters (so that it considers them initialized), the bigger question is how does the code for those functions gets loaded and unloaded, and which bpf programs have access to those functions. christos From owner-freebsd-net@FreeBSD.ORG Mon Aug 5 08:24:38 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 02D0543F; Mon, 5 Aug 2013 08:24:38 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id BBD2A2E8B; Mon, 5 Aug 2013 08:24:37 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id CF5727300A; Mon, 5 Aug 2013 10:23:07 +0200 (CEST) Date: Mon, 5 Aug 2013 10:23:07 +0200 From: Luigi Rizzo To: net@freebsd.org Subject: [net] protecting interfaces from races between control and data ? Message-ID: <20130805082307.GA35162@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: current@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 08:24:38 -0000 i am slightly unclear of what mechanisms we use to prevent races between interface being reconfigured (up/down/multicast setting, etc, all causing reinitialization of the rx and tx rings) and i) packets from the host stack being sent out; ii) interrupts from the network card being processed. I think in the old times IFF_DRV_RUNNING was used for this purpose, but now it is not enough. Acquiring the "core lock" in the NIC does not seem enough, either, because newer drivers, especially multiqueue ones, have per-queue rx and tx locks. Does anyone know if there is a generic mechanism, or each driver reimplements its own way ? thanks luigi From owner-freebsd-net@FreeBSD.ORG Mon Aug 5 08:57:14 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 04576CC6 for ; Mon, 5 Aug 2013 08:57:14 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm43-vm10.bullet.mail.bf1.yahoo.com (nm43-vm10.bullet.mail.bf1.yahoo.com [216.109.114.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 97D652FD3 for ; Mon, 5 Aug 2013 08:57:13 +0000 (UTC) Received: from [98.139.215.140] by nm43.bullet.mail.bf1.yahoo.com with NNFMP; 05 Aug 2013 08:57:06 -0000 Received: from [68.142.230.76] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 05 Aug 2013 08:57:06 -0000 Received: from [127.0.0.1] by smtp233.mail.bf1.yahoo.com with NNFMP; 05 Aug 2013 08:57:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1375693026; bh=g6MvKxMXufr38DVZ9QRpodvH8ZmW/f1OMpHnkowr2k4=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=gxNqdyBz7JXtFiVhtRTQtwlMJedchz/fzQ2nKd9QiylodjiJJYMW7NGGsOWcr9SwcXyrsB9DiQOytwrSWXWz0qaqqTI86tRLzvglbyOeylnS/AkrbZhMEbiiOLhqEWOwFBCR2YARG3LnpLNs119+VhpjTdxD5fGEFedvww+nOAo= X-Yahoo-Newman-Id: 186511.61154.bm@smtp233.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 2diJR4IVM1kXMFVXVWX7nonHpAFk90cHXkMTV.HVJZFXG1w llGVwNsKZkA_dNp9tT8IaIS4Rwgzk5TeqL.s6JXjitWlgoDlxhKHmuAD.6ng 5NzmGIuyP.atDetYsoBtg3tzW6H8xbYO2OQ8oafqcNI40hNuJ8FTj_QWF2J8 JAnZxH86Xg1sFVvl..Qr8ZrzUVjVtXYkC6TspXHtQJBS.PHoOe2p0F50oW7X _9eM8lnu5qexXTUjeHGReqSrkHy9Zkubjugbf.MJEg.wF7Ltg93Jk0EDQ8sE jbVu7P0MlNDBvCvk9rQ.HdSQc9LMFnRz7h6QeiYlNGEmlU7nSm9b4V0bFKyM JlOf.WeEE9S2bOWZ211_E6_K2z2tRMs7UKPtynZFeVtjkAAzK1cxXiA75Pe1 2gXdGUdrTJC52aJ3uzbYiUvlpieEFBZ8axKt.ABbjGKEawVd9Sv0bm9mP6_x J55hyCbfw_6mcYbqclk3YE2z5AWjh5dUqho3yZpXf8g8nRCLtT8XcJpAKXve gQhLOhlDq3IGkvf9BadwPLaWfOw6xDBO45ToDifPVoJVlyL33VEE_hRwHYg- - X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- X-Rocket-Received: from [192.168.254.206] (scott4long@168.103.85.57 with ) by smtp233.mail.bf1.yahoo.com with SMTP; 05 Aug 2013 08:57:06 +0000 UTC Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [net] protecting interfaces from races between control and data ? From: Scott Long In-Reply-To: <20130805082307.GA35162@onelab2.iet.unipi.it> Date: Mon, 5 Aug 2013 02:57:04 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <179713DC-926B-4E8A-9BE4-EC4337B8736E@yahoo.com> References: <20130805082307.GA35162@onelab2.iet.unipi.it> To: Luigi Rizzo X-Mailer: Apple Mail (2.1508) Cc: current@freebsd.org, net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 08:57:14 -0000 On Aug 5, 2013, at 2:23 AM, Luigi Rizzo wrote: > i am slightly unclear of what mechanisms we use to prevent races > between interface being reconfigured (up/down/multicast setting, etc, > all causing reinitialization of the rx and tx rings) and >=20 > i) packets from the host stack being sent out; > ii) interrupts from the network card being processed. >=20 > I think in the old times IFF_DRV_RUNNING was used for this purpose, > but now it is not enough. > Acquiring the "core lock" in the NIC does not seem enough, either, > because newer drivers, especially multiqueue ones, have per-queue > rx and tx locks. >=20 > Does anyone know if there is a generic mechanism, or each driver > reimplements its own way ? >=20 I'll speak to the RX side of the question. Several years ago I modified = the if_em driver to use a fast interrupt handler that would signal actual = processing in a taskqueue thread. The result was a system with no more latency = than the classic ithread model, but with the ability to allow RX processing = to be halted, drained, and restarted via an explicit API. This in turn was = extended to cause the RX processing to be safely paused during the control events that you described above. The system worked well on many fronts, but unfortunately I was unable to actively maintain it, and it was slowly garbage collected over time. I = think that it could have been extended without much effort to cover = TX-complete processing. TX dispatch is a different matter, but I don't think that = it would be hard to have the if_transmit/if_start path respond to control = synchronization events. Scott From owner-freebsd-net@FreeBSD.ORG Mon Aug 5 10:58:19 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AD98AB11; Mon, 5 Aug 2013 10:58:19 +0000 (UTC) (envelope-from menyy@mellanox.com) Received: from eu1sys200aog101.obsmtp.com (eu1sys200aog101.obsmtp.com [207.126.144.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 040FF24CC; Mon, 5 Aug 2013 10:57:57 +0000 (UTC) Received: from MTLCAS01.mtl.com ([193.47.165.155]) (using TLSv1) by eu1sys200aob101.postini.com ([207.126.147.11]) with SMTP ID DSNKUf+FGd6TA+4cijQmNuhLRYLmGp3kpFxc@postini.com; Mon, 05 Aug 2013 10:57:58 UTC Received: from MTLDAG01.mtl.com ([10.0.8.75]) by MTLCAS01.mtl.com ([10.0.8.71]) with mapi id 14.03.0123.003; Mon, 5 Aug 2013 13:49:03 +0300 From: Meny Yossefi To: "jhb@FreeBSD.org" , "freebsd-net@FreeBSD.org" Subject: RE: kern/180430: [ofed] [patch] Bad UDP checksum calc for fragmented packets Thread-Topic: kern/180430: [ofed] [patch] Bad UDP checksum calc for fragmented packets Thread-Index: AQHOiVTmYdNes7Ffukqso9x7GW3mRpmGf9KQ Date: Mon, 5 Aug 2013 10:49:01 +0000 Message-ID: References: <201307251634.r6PGYwQN069590@freefall.freebsd.org> In-Reply-To: <201307251634.r6PGYwQN069590@freefall.freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.13.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 10:58:19 -0000 John,=20 Will this be committed to 9.2 as well ? -Meny=20 -----Original Message----- From: jhb@FreeBSD.org [mailto:jhb@FreeBSD.org]=20 Sent: Thursday, July 25, 2013 7:35 PM To: Meny Yossefi; jhb@FreeBSD.org; freebsd-net@FreeBSD.org; jhb@FreeBSD.org Subject: Re: kern/180430: [ofed] [patch] Bad UDP checksum calc for fragment= ed packets Synopsis: [ofed] [patch] Bad UDP checksum calc for fragmented packets State-Changed-From-To: open->patched State-Changed-By: jhb State-Changed-When: Thu Jul 25 16:34:38 UTC 2013 State-Changed-Why:=20 Fix committed to HEAD, thanks! Responsible-Changed-From-To: freebsd-net->jhb Responsible-Changed-By: jhb Responsible-Changed-When: Thu Jul 25 16:34:38 UTC 2013 Responsible-Changed-Why:=20 Fix committed to HEAD, thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=3D180430 From owner-freebsd-net@FreeBSD.ORG Mon Aug 5 11:06:49 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 79D68F69 for ; Mon, 5 Aug 2013 11:06:49 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 65D6E25A4 for ; Mon, 5 Aug 2013 11:06:49 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r75B6ntj036157 for ; Mon, 5 Aug 2013 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r75B6nBc036155 for freebsd-net@FreeBSD.org; Mon, 5 Aug 2013 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 5 Aug 2013 11:06:49 GMT Message-Id: <201308051106.r75B6nBc036155@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 11:06:49 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/181006 net [run] [patch] mbuf leak in run(4) driver o kern/180893 net [if_ethersubr] [patch] Packets received with own LLADD o kern/180844 net [panic] [re] Intermittent panic (re driver?) o kern/180775 net [bxe] if_bxe driver broken with Broadcom BCM57711 card o kern/180722 net [bluetooth] bluetooth takes 30-50 attempts to pair to s kern/180468 net [request] LOCAL_PEERCRED support for PF_INET o kern/180065 net [netinet6] [patch] Multicast loopback to own host brok p kern/179975 net [igb] igb(4) fails to do polling(4) o kern/179926 net [lacp] [patch] active aggregator selection bug o kern/179824 net [ixgbe] System (9.1-p4) hangs on heavy ixgbe network t o kern/179733 net [lagg] [patch] interface loses capabilities when proto o kern/179429 net [tap] STP enabled tap bridge o kern/179299 net [igb] Intel X540-T2 - unstable driver a kern/179264 net [vimage] [pf] Core dump with Packet filter and VIMAGE o kern/178947 net [arp] arp rejecting not working o kern/178782 net [ixgbe] 82599EB SFP does not work with passthrough und o kern/178612 net [run] kernel panic due the problems with run driver o kern/178472 net [ip6] [patch] make return code consistent with IPv4 co o kern/178079 net [tcp] Switching TCP CC algorithm panics on sparc64 wit s kern/178071 net FreeBSD unable to recongize Kontron (Industrial Comput o kern/177905 net [xl] [panic] ifmedia_set when pluging CardBus LAN card o kern/177618 net [bridge] Problem with bridge firewall with trunk ports o kern/177417 net [ip6] Invalid protocol value in ipsec6_common_input_cb o kern/177402 net [igb] [pf] problem with ethernet driver igb + pf / alt o kern/177400 net [jme] JMC25x 1000baseT establishment issues o kern/177366 net [ieee80211] negative malloc(9) statistics for 80211nod f kern/177362 net [netinet] [patch] Wrong control used to return TOS o kern/177194 net [netgraph] Unnamed netgraph nodes for vlan interfaces o kern/177139 net [igb] igb drops ethernet ports 2 and 3 o kern/176884 net [re] re0 flapping up/down o kern/176671 net [epair] MAC address for epair device not unique o kern/176484 net [ipsec] [enc] [patch] panic: IPsec + enc(4); device na o kern/176446 net [netinet] [patch] Concurrency in ixgbe driving out-of- o kern/176420 net [kernel] [patch] incorrect errno for LOCAL_PEERCRED o kern/176419 net [kernel] [patch] socketpair support for LOCAL_PEERCRED o kern/176401 net [netgraph] page fault in netgraph o kern/176167 net [ipsec][lagg] using lagg and ipsec causes immediate pa o kern/176097 net [lagg] [patch] lagg/lacp broken when aggregated interf o kern/176027 net [em] [patch] flow control systcl consistency for em dr o kern/176026 net [tcp] [patch] TCP wrappers caused quite a lot of warni o bin/175974 net ppp(8): logic issue o kern/175864 net [re] Intel MB D510MO, onboard ethernet not working aft o kern/175852 net [amd64] [patch] in_cksum_hdr() behaves differently on o kern/175734 net no ethernet detected on system with EG20T PCH chipset o kern/175267 net [pf] [tap] pf + tap keep state problem o kern/175236 net [epair] [gif] epair and gif Devices On Bridge o kern/175182 net [panic] kernel panic on RADIX_MPATH when deleting rout o kern/175153 net [tcp] will there miss a FIN when do TSO? o kern/174959 net [net] [patch] rnh_walktree_from visits spurious nodes o kern/174958 net [net] [patch] rnh_walktree_from makes unreasonable ass o kern/174897 net [route] Interface routes are broken o kern/174851 net [bxe] [patch] UDP checksum offload is wrong in bxe dri o kern/174850 net [bxe] [patch] bxe driver does not receive multicasts o kern/174849 net [bxe] [patch] bxe driver can hang kernel when reset o kern/174822 net [tcp] Page fault in tcp_discardcb under high traffic o kern/174602 net [gif] [ipsec] traceroute issue on gif tunnel with ipse o kern/174535 net [tcp] TCP fast retransmit feature works strange o kern/173871 net [gif] process of 'ifconfig gif0 create hangs' when if_ o kern/173475 net [tun] tun(4) stays opened by PID after process is term o kern/173201 net [ixgbe] [patch] Missing / broken ixgbe sysctl's and tu o kern/173137 net [em] em(4) unable to run at gigabit with 9.1-RC2 o kern/173002 net [patch] data type size problem in if_spppsubr.c o kern/172895 net [ixgb] [ixgbe] do not properly determine link-state o kern/172683 net [ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos o kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/171739 net [bce] [panic] bce related kernel panic o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net [ndis] undocumented dependency for ndis(4) o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169664 net [bgp] Wrongful replacement of interface connected net o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis p kern/165903 net mbuf leak o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155680 net [multicast] problems with multicast s kern/155642 net [new driver] [request] Add driver for Realtek RTL8191S o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [new driver] [request]: Port brcm80211 driver from Lin o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl p kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph f kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121534 net [ipl] [nat] FreeBSD Release 6.3 Kernel Trap 12: o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] f kern/108197 net [panic] [gif] [ip6] if_delmulti reference counting pan o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104738 net [inet] [patch] Reentrant problem with inet_ntoa in the o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 456 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Aug 5 11:20:44 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1AABDD61 for ; Mon, 5 Aug 2013 11:20:44 +0000 (UTC) (envelope-from rnewpol@panasas.com) Received: from natasha.panasas.com (natasha.panasas.com [67.152.220.90]) by mx1.freebsd.org (Postfix) with ESMTP id D272527FD for ; Mon, 5 Aug 2013 11:20:43 +0000 (UTC) Received: from zenyatta.panasas.com (zenyatta.int.panasas.com [172.17.28.63]) by natasha.panasas.com (8.13.1/8.13.1) with ESMTP id r75BKaS0020984 for ; Mon, 5 Aug 2013 07:20:36 -0400 Received: from ZENYATTA.int.panasas.com ([fe80::44ca:f0e1:b97e:bf79]) by zenyatta.int.panasas.com ([fe80::44ca:f0e1:b97e:bf79%15]) with mapi id 14.01.0438.000; Mon, 5 Aug 2013 07:20:36 -0400 From: "Newpol, Richard" To: "freebsd-net@freebsd.org" Subject: RE: Adding an address to a downed LAGG interface breaks it? Thread-Topic: Adding an address to a downed LAGG interface breaks it? Thread-Index: Ac6O0kNU3I+mB/omSF2T80LhN/f9IAClM6uAABmYI9U= Date: Mon, 5 Aug 2013 11:20:35 +0000 Message-ID: <1A778AD3F807B340B7EB1BD1B9C196773D6566C8@zenyatta.int.panasas.com> References: <1A778AD3F807B340B7EB1BD1B9C196773D655FE6@zenyatta.int.panasas.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.28.30] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 11:20:44 -0000 By "inconsistent state" i just mean that the driver is not actually up, but= the IFF_UP flag is set. The problem is that when the interface is brought = up by the user after that (ifconfig lagg0 up), the part of the code that ad= ds the default subnet broadcast routes checks IFF_UP and sees it is set, so= it skips the route adds. Normally, the route adds (and a few other things)= are done before the IFF_UP flag is set.=0A= =0A= Rich Newpol=0A= Panasas=0A= ________________________________________=0A= From: Rui Paulo [rpaulo@FreeBSD.org]=0A= Sent: Sunday, August 04, 2013 3:05 PM=0A= To: Newpol, Richard=0A= Cc: freebsd-net@freebsd.org=0A= Subject: Re: Adding an address to a downed LAGG interface breaks it?=0A= =0A= On 1 Aug 2013, at 09:22, "Newpol, Richard" wrote:=0A= =0A= > All,=0A= > We seem to have discovered a problem that occurs when adding an address (= or alias) to a DOWNed lagg interface. After adding an address, when you try= to bring the interface UP it can't reach the desired networks.=0A= >=0A= > Turns out that the problem occurs because the lagg driver silently passes= the SIOCSIFADDR ioctl to the "ether_ioctl" handler, which in turn always s= ets the IFF_UP flag.=0A= >=0A= > While this is usually ok (since ifconfig
implies UP with t= he first assigned address anyway), the lagg driver does not have the proper= handling to actually change state to UP on the first address, so it ends u= p in an inconsistent state. Then, when the user eventually does an "ifconfi= g lagg up" the default subnet routes are not added (because the "interface = up" code sees that IFF_UP is already set).=0A= >=0A= > So my first question - is this a known problem, or has it been addressed = in some other way?=0A= >=0A= > Secondly, I can think of two ways to fix this, and was wondering what are= the implications. The first way would be for the lagg driver to correctly = bring itself up when the first address is added to it. The second way would= be for the lagg driver to preserve the state of IFF_FLAG when handling SIO= CSIFADDR. I like the second way because it is less of an overall behaviour = change from the current, but the first way seems more correct.=0A= =0A= =0A= After you add the first address, you said it comes to an inconsistent state= . Can you clarify?=0A= =0A= The first approach seems like the right fix but I don't know much about the= problem. The second way breaks the POLA because you're special casing lagg= just to work around a bug.=0A= =0A= --=0A= Rui Paulo=0A= =0A= From owner-freebsd-net@FreeBSD.ORG Mon Aug 5 14:59:44 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2C02C6D9; Mon, 5 Aug 2013 14:59:44 +0000 (UTC) (envelope-from bryanv@daemoninthecloset.org) Received: from torment.daemoninthecloset.org (torment.daemoninthecloset.org [94.242.209.234]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E113E2175; Mon, 5 Aug 2013 14:59:43 +0000 (UTC) Received: from sage.daemoninthecloset.org (unknown [70.114.209.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sage.daemoninthecloset.org", Issuer "daemoninthecloset.org" (verified OK)) by torment.daemoninthecloset.org (Postfix) with ESMTPS id C5F5542C082F; Mon, 5 Aug 2013 17:03:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemoninthecloset.org X-Virus-Scanned: amavisd-new at daemoninthecloset.org Date: Mon, 5 Aug 2013 09:59:32 -0500 (CDT) From: Bryan Venteicher To: Luigi Rizzo Message-ID: <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> In-Reply-To: <20130805082307.GA35162@onelab2.iet.unipi.it> References: <20130805082307.GA35162@onelab2.iet.unipi.it> Subject: Re: [net] protecting interfaces from races between control and data ? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.51.1.6] X-Mailer: Zimbra 8.0.2_GA_5569 (ZimbraWebClient - GC28 (Mac)/8.0.2_GA_5569) Thread-Topic: protecting interfaces from races between control and data ? Thread-Index: XB5cQkjSbdk+U+3uKm786A9OXRt2+g== Cc: current@freebsd.org, net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 14:59:44 -0000 ----- Original Message ----- > i am slightly unclear of what mechanisms we use to prevent races > between interface being reconfigured (up/down/multicast setting, etc, > all causing reinitialization of the rx and tx rings) and > > i) packets from the host stack being sent out; > ii) interrupts from the network card being processed. > > I think in the old times IFF_DRV_RUNNING was used for this purpose, > but now it is not enough. > Acquiring the "core lock" in the NIC does not seem enough, either, > because newer drivers, especially multiqueue ones, have per-queue > rx and tx locks. > What I've done in my drivers is: * Lock the core mutex * Clear IFF_DRV_RUNNING * Lock/unlock each queue's lock The various Rx/Tx queue functions check for IFF_DRV_RUNNING after (re)acquiring their queue lock. See at vtnet_stop_rendezvous() at [1] for an example. > Does anyone know if there is a generic mechanism, or each driver > reimplements its own way ? > We desperately need a saner ifnet/driver interface. I think andre@ had some previous work in this area (and additional plans as well?). IMO, there's a lot to like on what DragonflyBSD has done in this area. [1] - http://svnweb.freebsd.org/base/user/bryanv/vtnetmq/sys/dev/virtio/network/if_vtnet.c?revision=252451&view=markup > thanks > luigi > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Aug 5 15:46:07 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9FFCFAAA; Mon, 5 Aug 2013 15:46:07 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0ED8F240B; Mon, 5 Aug 2013 15:46:06 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id hr7so1688988wib.12 for ; Mon, 05 Aug 2013 08:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=wcEuz7SwM5lnp1ELEuS15xUD9fl379Cc+SC2aQRyM78=; b=tcOyfMPS041odEFpBwOXKVh3RL9uDtZGC5KYflLdbx/bEezHlUCNgeKvTJzAi6h/yy h1z44vSNFYQWO8N0LdNqaehfXX53/vS9Hf1Iy6c0PjQ7jgqLkv4I3g/f7VNbB1URoux+ EYL9yvIUL4baqHjIsHNW1JMToKPjz3wSZ6ybdL9DKKvYZczxCgzxmnS/7YYr+qirCXM+ wmxgPaEwr6VZMfBEOA5JcQXIygAi9rO7F+fdlsNiorXDQcykENFZ95xsZLZmM9NBNUFF Gez1mdGngJ8Mo83Jlxgbpy1TwAekc+enhL1c5seJVSsAMclieiARV09noAa1rGB4Drds p4CQ== MIME-Version: 1.0 X-Received: by 10.180.160.165 with SMTP id xl5mr7139867wib.46.1375717565346; Mon, 05 Aug 2013 08:46:05 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Mon, 5 Aug 2013 08:46:05 -0700 (PDT) In-Reply-To: <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> Date: Mon, 5 Aug 2013 08:46:05 -0700 X-Google-Sender-Auth: LktrRb4KALl0kOzD1nz2ankEW3E Message-ID: Subject: Re: [net] protecting interfaces from races between control and data ? From: Adrian Chadd To: Bryan Venteicher Content-Type: text/plain; charset=ISO-8859-1 Cc: Luigi Rizzo , current@freebsd.org, net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 15:46:07 -0000 On 5 August 2013 07:59, Bryan Venteicher wrote: > What I've done in my drivers is: > * Lock the core mutex > * Clear IFF_DRV_RUNNING > * Lock/unlock each queue's lock .. and I think that's the only sane way of doing it. I'm going to (soon) propose something similar for cxgbe/ixgbe as we use these NICs at work, then feed this experiment back into the network stack so we can have a unified way of doing this. You may also want to synchronize against the driver TX/RX/core locks and state when doing things like, say, halting DMA in preparation for multicast reprogramming on some hardware; or even doing a chip reset. I had to hand-roll this for ath(4) to make it completely correct - any kind of overlapping reset, reset during TX, reset during RX etc would cause all kinds of instability and random-crap-scribbled-everywhere issues. So yes, this is a larger scale issue that needs to be solved. -adrian From owner-freebsd-net@FreeBSD.ORG Mon Aug 5 16:15:03 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5B4354AF; Mon, 5 Aug 2013 16:15:03 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7591525C2; Mon, 5 Aug 2013 16:15:02 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id mf11so2250829lab.15 for ; Mon, 05 Aug 2013 09:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=IJksw33/x2N791vbphuUxZFdCSsyAGGfakfCm7Zm1ZM=; b=G5yyLzkkK27DPQds8L9nO+pLwGpJ2CvPfINDIwkoazj8QaoUeeO6ji2TZII5VyxGPO 00O3NKADwIAexY7Q1nhCLiDm3fRycEbDF1UznUVCF6JV9PQA79GiHFglQ3UiDA7jeS1H xD9EoaA/B+iCEK4HXm8QwGNUPJKfDkCasjEgaxQQmRrq8lnvDNmQCwGjSAW7+xJFIRAF kle3tiPyIV2EKjdWIbwVit6uy/x3vaoO3lv12VcCj0ERW5yA0KHN3SaB0UeAnq3A+vk/ J7XCZmkyGNfVpfCNVuXm1WoSU951o9OaG7Qe/LvRxK00EVFkHSupg5KpRTh+NtYMszCM otyg== MIME-Version: 1.0 X-Received: by 10.152.87.42 with SMTP id u10mr1630303laz.43.1375719300456; Mon, 05 Aug 2013 09:15:00 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.200.165 with HTTP; Mon, 5 Aug 2013 09:15:00 -0700 (PDT) In-Reply-To: References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> Date: Mon, 5 Aug 2013 18:15:00 +0200 X-Google-Sender-Auth: k8hbls4GhIGp5BnB4loRnZejBkY Message-ID: Subject: Re: [net] protecting interfaces from races between control and data ? From: Luigi Rizzo To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Giuseppe Lettieri , Bryan Venteicher , current@freebsd.org, net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 16:15:03 -0000 On Mon, Aug 5, 2013 at 5:46 PM, Adrian Chadd wrote: > On 5 August 2013 07:59, Bryan Venteicher > wrote: > > > What I've done in my drivers is: > > * Lock the core mutex > > * Clear IFF_DRV_RUNNING > > * Lock/unlock each queue's lock > > .. and I think that's the only sane way of doing it. > yeah, this was also the solution we had in mind, i was surprised not find this pattern in the drivers i have looked at. Also there are drivers (chelsio ?) which do not seem to have locks on the receive interrupt handlers ? Does anyone know how linux copes with the same problem ? They seem to have an rtnl_lock() which is a global lock for all configuration of netdevices (would replace our per-interface 'core lock' above), but i am totally unclear on how individual tx threads and interrupt handlers acknowledge that they have read the change in status. cheers luigi From owner-freebsd-net@FreeBSD.ORG Mon Aug 5 17:13:06 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3EC73660; Mon, 5 Aug 2013 17:13:06 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0419B28FB; Mon, 5 Aug 2013 17:13:05 +0000 (UTC) Received: by mail-pd0-f173.google.com with SMTP id p11so3487338pdj.32 for ; Mon, 05 Aug 2013 10:13:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=A6dgrK6zlFFan2PwgEg8Zx3im9qX+MeYm0qKZqwqixM=; b=l+uJEts6N3ktFpMtF3evI3UU3SelqeTx70qqu2lEXYF6JS6JeSKycuiSQ1D1JVK2SE QWGYv/n2uVjEas3BSdJ6wQ+fGJCAM/E+Z5ZOkXo+0gc4u+A1JMHgzYA0o2lG4P+T/2cJ vl8owDLacwtCu5Y8eh9Iz7AkYpwji7bUGFm+GGI7GJv7iPzsrZLJvW6FS7Z2Xo6E1yPx IDFU3/DJJsVcCm1s9nnh3fkfg6IRtTbm3vjJPLN1T6QGtzdA0M//NoSdU+2f5LeDRjvU zH3yyIJ4Yod+8HTibQ7a3idjvxClzp6njBiZ+nMwXuyTWhboHCSSypvxCZDcYywgs7Wu 4bYg== X-Received: by 10.68.169.97 with SMTP id ad1mr23138366pbc.84.1375722785646; Mon, 05 Aug 2013 10:13:05 -0700 (PDT) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPSA id qc5sm99574pbc.31.2013.08.05.10.13.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 Aug 2013 10:13:04 -0700 (PDT) Sender: Navdeep Parhar Message-ID: <51FFDD1E.1000206@FreeBSD.org> Date: Mon, 05 Aug 2013 10:13:02 -0700 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130731 Thunderbird/17.0.7 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: [net] protecting interfaces from races between control and data ? References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , net@freebsd.org, Bryan Venteicher , Giuseppe Lettieri , current@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 17:13:06 -0000 On 08/05/13 09:15, Luigi Rizzo wrote: > On Mon, Aug 5, 2013 at 5:46 PM, Adrian Chadd wrote: > >> On 5 August 2013 07:59, Bryan Venteicher >> wrote: >> >>> What I've done in my drivers is: >>> * Lock the core mutex >>> * Clear IFF_DRV_RUNNING >>> * Lock/unlock each queue's lock >> >> .. and I think that's the only sane way of doing it. >> > > yeah, this was also the solution we had in mind, i was surprised > not find this pattern in the drivers i have looked at. > > Also there are drivers (chelsio ?) which do not seem to have locks on the > receive interrupt handlers ? This is correct. cxgbe(4) does not have any locks on rx, just a "state" for each rx queue that's maintained with atomic ops. Regards, Navdeep > > Does anyone know how linux copes with the same problem ? > > They seem to have an rtnl_lock() which is a global lock for all > configuration > of netdevices (would replace our per-interface 'core lock' above), > but i am totally unclear on how individual tx threads and interrupt handlers > acknowledge that they have read the change in status. > > cheers > luigi > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Aug 5 17:17:30 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 48085886; Mon, 5 Aug 2013 17:17:30 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 81BD7295A; Mon, 5 Aug 2013 17:17:29 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id p58so2687490wes.40 for ; Mon, 05 Aug 2013 10:17:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=53AuICVCdcZlIghBYscnVB5whDr/1xVLfYIPIe4O16U=; b=h/gmYHTWNFnwUvRBYGPA6SDt4GD2n/jo+fzv4NUxKgnwpxKInBTDfuSRWJ/dfZfj10 2l/nySiD+H1tqhMll727a2vf9LChWGUzma5UVnEBmWCqdsxKqPWR8TFL1aNWHmJQ/TlH CiHBER8erGa1RRj97541I6dHet1Ohfai0+0Yi51Qr6kbQdN0iIs9DGKDKXcjrDHGo/O3 8RmnABsBelJw8lgnU8n+y2SBNcziTuzwnnVqDwDIF/FTxUEht+ylabFsLKVY2UbSLbHs 4AG7njqS8+4BXPzvqvwVKoey9fN4YSG42NBJ2/mx6DHyaDKcS60l30HnndMGtAors8S1 hjMw== MIME-Version: 1.0 X-Received: by 10.180.185.148 with SMTP id fc20mr7612847wic.0.1375723047877; Mon, 05 Aug 2013 10:17:27 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Mon, 5 Aug 2013 10:17:27 -0700 (PDT) In-Reply-To: <51FFDD1E.1000206@FreeBSD.org> References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> Date: Mon, 5 Aug 2013 10:17:27 -0700 X-Google-Sender-Auth: xvHHdnO8uRlzvUdaJTkNkn7V8Fo Message-ID: Subject: Re: [net] protecting interfaces from races between control and data ? From: Adrian Chadd To: Navdeep Parhar Content-Type: text/plain; charset=ISO-8859-1 Cc: Bryan Venteicher , Giuseppe Lettieri , Luigi Rizzo , current@freebsd.org, net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 17:17:30 -0000 I'm travelling back to San Jose today; poke me tomorrow and I'll brain dump what I did in ath(4) and the lessons learnt. The TL;DR version - you don't want to grab an extra lock in the read/write paths as that slows things down. Reuse the same per-queue TX/RX lock and have: * a reset flag that is set when something is resetting; that says to the queue "don't bother processing anything, just dive out"; * 'i am doing Tx / Rx' flags per queue that is set at the start of TX/RX servicing and finishes at the end; that way the reset code knows if there's something pending; * have the reset path grab each lock, set the 'reset' flag on each, then walk each queue again and make sure they're all marked as 'not doing TX/RX'. At that point the reset can occur, then the flag cna be cleared, then TX/RX can resume. -adrian On 5 August 2013 10:13, Navdeep Parhar wrote: > On 08/05/13 09:15, Luigi Rizzo wrote: >> On Mon, Aug 5, 2013 at 5:46 PM, Adrian Chadd wrote: >> >>> On 5 August 2013 07:59, Bryan Venteicher >>> wrote: >>> >>>> What I've done in my drivers is: >>>> * Lock the core mutex >>>> * Clear IFF_DRV_RUNNING >>>> * Lock/unlock each queue's lock >>> >>> .. and I think that's the only sane way of doing it. >>> >> >> yeah, this was also the solution we had in mind, i was surprised >> not find this pattern in the drivers i have looked at. >> >> Also there are drivers (chelsio ?) which do not seem to have locks on the >> receive interrupt handlers ? > > This is correct. cxgbe(4) does not have any locks on rx, just a "state" > for each rx queue that's maintained with atomic ops. > > Regards, > Navdeep > > >> >> Does anyone know how linux copes with the same problem ? >> >> They seem to have an rtnl_lock() which is a global lock for all >> configuration >> of netdevices (would replace our per-interface 'core lock' above), >> but i am totally unclear on how individual tx threads and interrupt handlers >> acknowledge that they have read the change in status. >> >> cheers >> luigi >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > From owner-freebsd-net@FreeBSD.ORG Mon Aug 5 17:20:15 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6D08DA6B; Mon, 5 Aug 2013 17:20:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A607C2997; Mon, 5 Aug 2013 17:20:14 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id j17so1795681wiw.17 for ; Mon, 05 Aug 2013 10:20:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Z0qqlvZSbYYLwmIdMg8zl/qe3mxUzG93G0K4/kOzScY=; b=ckD4n2U9qLwrdUtA9Ciz+MfDiedcLFccJcofzCt8GGnwvw/aTSitKmig59gXpJGGUu WxJYNDsI1vcXuQOq58YoRc1uls+mh8fIMsfb6xy7fbFN0Ok+fyDXlEnirrNIzmOEQdYc 24VZ8WaChaHPp+3q3lLaGNP5d64s18wOFlkcjf7AyUsc+3uda9V/pJSwgnB/0vR/2kSy PQc9YRpdJMG74phBDqk+5BT2v1F+OOQeadVg08+bGfHH1jwefqGmobiHvOQZg65IoE3/ 8GWRIkXbhOtl94uPNFJz0/KmQHb6ljoKTsUMJ5qmu2zZOfIN/jqtm+4op11Wluddb99s RRew== MIME-Version: 1.0 X-Received: by 10.194.201.202 with SMTP id kc10mr14057689wjc.1.1375723212843; Mon, 05 Aug 2013 10:20:12 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Mon, 5 Aug 2013 10:20:12 -0700 (PDT) In-Reply-To: References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> Date: Mon, 5 Aug 2013 10:20:12 -0700 X-Google-Sender-Auth: 2-qcTBCZjB_LRkVkLpTgqOsD12Q Message-ID: Subject: Re: [net] protecting interfaces from races between control and data ? From: Adrian Chadd To: Navdeep Parhar Content-Type: text/plain; charset=ISO-8859-1 Cc: Bryan Venteicher , Giuseppe Lettieri , Luigi Rizzo , current@freebsd.org, net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 17:20:15 -0000 .. and I bet it's not a design pattern, and this is total conjecture on my part: * the original drivers weren't SMP safe; * noone really sat down and figured out how to correctly synchronise all of this stuff; * people did the minimum amount of work to keep the driver from immediately crashing, but didn't really think things through at a larger scale. Almost every driver is this way Luigi. :-) -adrian From owner-freebsd-net@FreeBSD.ORG Mon Aug 5 17:32:12 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 668D6252 for ; Mon, 5 Aug 2013 17:32:12 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm13.bullet.mail.ne1.yahoo.com (nm13.bullet.mail.ne1.yahoo.com [98.138.90.76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 041F62A85 for ; Mon, 5 Aug 2013 17:32:11 +0000 (UTC) Received: from [98.138.90.56] by nm13.bullet.mail.ne1.yahoo.com with NNFMP; 05 Aug 2013 17:32:04 -0000 Received: from [98.138.226.127] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 05 Aug 2013 17:32:04 -0000 Received: from [127.0.0.1] by smtp206.mail.ne1.yahoo.com with NNFMP; 05 Aug 2013 17:32:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1375723924; bh=YiS4NvFfaKQ8oewMV8XxgvkG12NOLehq+k67gYJZaok=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=bszIC1LJKRZMcjmLLa4+S54WpbnnkBNUQgSZuR5vRjBm+09N4HA8e2LDABIsUvDGTlqSIjWOMdT+9TDKzfe3kV1oS1LzoM8Piy3iMmmeU1I0GjHGd+XGp6D15yyneKn1AzCP9W79zwFj6N4GJw15gXUxKO9rjgKLW9qMq1NBvkM= X-Yahoo-Newman-Id: 697595.10846.bm@smtp206.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: qJrqZAkVM1n1eOIWn9ZHv7Bd1ajC776U11nuLqzRMtf.vl0 trVo7Gmmdr_AtuZsuYUYtGO69JamoOQkDHdXKUzccGSeotnZzCQrIxarpj3z jVm8NU0bHmCgTeKSEgv3uUFFH5.JYuuncnwWjTpDuBblyroyTnBwapUa8v_b q5GYrd6eYcMNKt1ZdWkTkOlYslg7olzBsUl1AOJJ7_igPT.wf33mILokhhDh S2nc.jmTYF0ug3rR9Tzmd0MEVH5PM8Yi9hqGzQkTp9gpTjxwvqqKxCzYt0LZ UPWlGCLFyVC33JJsA5_xIJ0rPgUCbaEx2owVV7uS6hNbDbYcINMeMllIhA4m y4yP9joYI5yjoxNE5omceTcUHDlmC4CYQJoBf.ZQEbkvtOc3wH7KRnY.K0Wp ko.15VteDiPGq.kiSmrdrswrVeJzLhJHUU2NpS1RlPfePFtxRlkK7T1KFEZO 4I.gcYBqa5BOlMSC0J30xF4Rah93NgiBAxza_ZxFkjz0byrvNfC8TRHUnzze dqpHcDL3bk0Y5O28ihS7m4z05jZTE6Qoswzzas3K0BIxE5..DyWsdnr9MfA- - X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- X-Rocket-Received: from lgmc-adee.corp.netflix.com (scott4long@69.53.237.126 with ) by smtp206.mail.ne1.yahoo.com with SMTP; 05 Aug 2013 10:32:04 -0700 PDT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [net] protecting interfaces from races between control and data ? From: Scott Long In-Reply-To: Date: Mon, 5 Aug 2013 11:32:02 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <195AEBBF-4297-4570-9D38-954FEC8D08DB@yahoo.com> References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1508) Cc: current@freebsd.org, Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri , Luigi Rizzo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 17:32:12 -0000 On Aug 5, 2013, at 11:20 AM, Adrian Chadd wrote: > .. and I bet it's not a design pattern, and this is total conjecture = on my part: >=20 > * the original drivers weren't SMP safe; > * noone really sat down and figured out how to correctly synchronise > all of this stuff; > * people did the minimum amount of work to keep the driver from > immediately crashing, but didn't really think things through at a > larger scale. >=20 > Almost every driver is this way Luigi. :-) >=20 >=20 Yes, but let me expand. The original work to make NIC drivers SMP = focused around just putting everything under 1 lock. The lock was acquired in if_start and held through the transmission of the packet, it was held in if_ioctl all the way through whatever action was taken, and it was held = in the interrupt handler over all of the RX and TX-complete processing. = This worked fine up until the RX path called if_input() with the netisr path = set for direct dispatch. In this mode, the code could flow up the stack and then immediately back down into the if_start handler for the driver, where it would try to acquire the same lock again. Also, it meant that forwarding packets between to interfaces would have the lock from the RX context of one interface held into the TX context of the other = interface. Obviously, this was a big mess, so the "solution" was to just drop the lock around the call to if_input(). No consideration was made for = driver state that might change during the lock release, nor was any = consideration made for the performance impact of dropping the lock on every packet and then having to contend with top-half TX threads to pick it back up. But this became the quick-fix pattern. As for the original question of why the RX path can operate unlocked, = it's fairly easy. The RX machinery of most NICs is fairly separate from the = TX machinery, so little synchronization is needed. When there's a state = change in the driver, in terms of an interface going down, a queue size = changing, or the driver being unloaded, it's up to the driver to pause and drain = the RX processing prior to this state change. It worked well when I did it = in if_em, and it appears to work well with cxgbe. Scott From owner-freebsd-net@FreeBSD.ORG Mon Aug 5 17:36:25 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5F3944B1; Mon, 5 Aug 2013 17:36:25 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 45D9E2AB1; Mon, 5 Aug 2013 17:36:24 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id ec20so2311991lab.28 for ; Mon, 05 Aug 2013 10:36:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=2rzT9Cecv/nAAHnMXSQ2bQxtOaPUdNq7iwzZrH2pVpQ=; b=l76mt1SMaPw/l3wWNi95/3Lt+IP+/kK07ID/9fhMJhC1ldi+EyzS2B7daf3tpDff+b q8zU8u957hmw/ryINMzjhXDB9men0kpa+vZSVDsCv7S4PdUPXg0ek6XcnzEykiFCcQB9 RQ8sr2tGfNJR65BgjPfQ0qWGUmNrp2J/vwESarQkhmLlAdgeS/rJhdeEhKqR00ykODEL pmp8moaoUct4+zFpmHe24hHOPwZakmxkSgEx4f+g51B1IqjKHdHNOSoEikB9MZCp0bHl VcyOhl75aAp+3DUaMbGfILQRb1imbvn5uOzJk64RK0WY6C2D4nMX2fWbNvzfap0ak/Mn yXcw== MIME-Version: 1.0 X-Received: by 10.112.11.20 with SMTP id m20mr1297788lbb.56.1375724182270; Mon, 05 Aug 2013 10:36:22 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.200.165 with HTTP; Mon, 5 Aug 2013 10:36:22 -0700 (PDT) In-Reply-To: References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> Date: Mon, 5 Aug 2013 19:36:22 +0200 X-Google-Sender-Auth: bRXHtflqCqaEThiVs5xN7NeSKLw Message-ID: Subject: Re: [net] protecting interfaces from races between control and data ? From: Luigi Rizzo To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Giuseppe Lettieri , net@freebsd.org, Bryan Venteicher , Navdeep Parhar , current@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 17:36:25 -0000 On Mon, Aug 5, 2013 at 7:17 PM, Adrian Chadd wrote: > I'm travelling back to San Jose today; poke me tomorrow and I'll brain > dump what I did in ath(4) and the lessons learnt. > > The TL;DR version - you don't want to grab an extra lock in the > read/write paths as that slows things down. Reuse the same per-queue > TX/RX lock and have: > > * a reset flag that is set when something is resetting; that says to > the queue "don't bother processing anything, just dive out"; > * 'i am doing Tx / Rx' flags per queue that is set at the start of > TX/RX servicing and finishes at the end; that way the reset code knows > if there's something pending; > * have the reset path grab each lock, set the 'reset' flag on each, > then walk each queue again and make sure they're all marked as 'not > doing TX/RX'. At that point the reset can occur, then the flag cna be > cleared, then TX/RX can resume. > so this is slightly different from what Bryan suggested (and you endorsed) before, as in that case there was a single 'reset' flag IFF_DRV_RUNNING protected by the 'core' lock, then a nested round on all tx and rx locks to make sure that all customers have seen it. In both cases the tx and rx paths only need the per-queue lock. As i see it, having a per-queue reset flag removes the need for nesting core + queue locks, but since this is only in the control path perhaps it is not a big deal (and is better to have a single place to look at to tell whether or not we should bail out). cheers luigi From owner-freebsd-net@FreeBSD.ORG Mon Aug 5 17:49:16 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6C19BC05; Mon, 5 Aug 2013 17:49:16 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DEC7B2B89; Mon, 5 Aug 2013 17:49:15 +0000 (UTC) Received: by mail-ve0-f172.google.com with SMTP id oz10so3461306veb.17 for ; Mon, 05 Aug 2013 10:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=D2+WuzNylDlrVMC06bwGlyCSnDekeP0XfKz+Pa93Yl4=; b=nIFFGrcckToaxZY3qQFYcX4tffziKnp2PPzwie3r+uzqDQFlQ44uuXcxFoqe9txZsg thCq0HR83GikytJ596Q1wK8GHvHTZ9ON2M+X06z3XDs//PcyMB+lBNcBoGuzngZP/6QL GWrYotUgeuCoP3nYrNMAZqDvWez+hP6Hr/Pphb85Hpl5GEvK7u8q5NtfD1s9/eoiSTiR M09l/k5XYV1Zkl0uuqrguhhtGBUIaqUISYGJDBkmLdggX17oIHqCgdQYLWTCobA4L7Uy WfJYcyXvHALgqERdUaw4ocO7TFvawJ8kEr4HuiTzAlEaYsMPaoq4XVCfU5iXYTIFW+kT 2DMg== MIME-Version: 1.0 X-Received: by 10.52.117.174 with SMTP id kf14mr5128392vdb.26.1375724955058; Mon, 05 Aug 2013 10:49:15 -0700 (PDT) Received: by 10.220.159.141 with HTTP; Mon, 5 Aug 2013 10:49:14 -0700 (PDT) In-Reply-To: References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> Date: Mon, 5 Aug 2013 10:49:14 -0700 Message-ID: Subject: Re: [net] protecting interfaces from races between control and data ? From: Jack Vogel To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Adrian Chadd , FreeBSD current mailing list , Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 17:49:16 -0000 Sigh, this ends up being ugly I'm afraid. I need some time to look at code and think about it. Jack On Mon, Aug 5, 2013 at 10:36 AM, Luigi Rizzo wrote: > On Mon, Aug 5, 2013 at 7:17 PM, Adrian Chadd wrote: > > > I'm travelling back to San Jose today; poke me tomorrow and I'll brain > > dump what I did in ath(4) and the lessons learnt. > > > > The TL;DR version - you don't want to grab an extra lock in the > > read/write paths as that slows things down. Reuse the same per-queue > > TX/RX lock and have: > > > > * a reset flag that is set when something is resetting; that says to > > the queue "don't bother processing anything, just dive out"; > > * 'i am doing Tx / Rx' flags per queue that is set at the start of > > TX/RX servicing and finishes at the end; that way the reset code knows > > if there's something pending; > > * have the reset path grab each lock, set the 'reset' flag on each, > > then walk each queue again and make sure they're all marked as 'not > > doing TX/RX'. At that point the reset can occur, then the flag cna be > > cleared, then TX/RX can resume. > > > > so this is slightly different from what Bryan suggested (and you endorsed) > before, as in that case there was a single 'reset' flag IFF_DRV_RUNNING > protected by the 'core' lock, then a nested round on all tx and rx locks > to make sure that all customers have seen it. > In both cases the tx and rx paths only need the per-queue lock. > > As i see it, having a per-queue reset flag removes the need for nesting > core + queue locks, but since this is only in the control path perhaps > it is not a big deal (and is better to have a single place to look at to > tell whether or not we should bail out). > > cheers > luigi > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Aug 5 17:58:59 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C27597D; Mon, 5 Aug 2013 17:58:59 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 92C162C17; Mon, 5 Aug 2013 17:58:58 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id ec20so2316316lab.0 for ; Mon, 05 Aug 2013 10:58:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=6ZtvieGuGGhAoaS120XU/yBY9J5erKykOaKC1g2RHZM=; b=UDqfQxf4mqMb/UO47n6zUdZVEG+2QScx44XHXDKrGBij62yi6VgwfstSwP/4mRjeuP C3i1p87rUezNa7tErAFgfUfxtWM0zMzWIF4HLrgAZDYfYzvMxQ/1y3rwFKsabmX94ICk kdEOYdrztO04jq/AsqhYvRB4X2RlpLRvc629P/97Eh3gCL9o6vIRU7XqY+ObccFghCuh Ybgbw+wlWKU66CxpjwycKgZDFDF2gE+J+yMa6Uf8lUBcRZ1OTAp/J6CpfdDBfW4Gw1xr lk5eNM12nASMeUTxeAk0bbnUclap+UbbBppZnQPM7pRf0MA/YcO+auRNOOXIZ2rSKBv5 S9Xw== MIME-Version: 1.0 X-Received: by 10.152.36.198 with SMTP id s6mr5661194laj.67.1375725536550; Mon, 05 Aug 2013 10:58:56 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.200.165 with HTTP; Mon, 5 Aug 2013 10:58:56 -0700 (PDT) In-Reply-To: References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> Date: Mon, 5 Aug 2013 19:58:56 +0200 X-Google-Sender-Auth: -7AMBJyuIckaxEZBCuXlzZJHyq0 Message-ID: Subject: Re: [net] protecting interfaces from races between control and data ? From: Luigi Rizzo To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Adrian Chadd , FreeBSD current mailing list , Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 17:58:59 -0000 On Mon, Aug 5, 2013 at 7:49 PM, Jack Vogel wrote: > Sigh, this ends up being ugly I'm afraid. I need some time to look at code > and think about it. > > actually the intel drivers seem in decent shape, especially if we reuse IFF_DRV_RUNNING as the reset flag and the core+queue lock in the control path. cheers luigi > Jack > > > > On Mon, Aug 5, 2013 at 10:36 AM, Luigi Rizzo wrote: > >> On Mon, Aug 5, 2013 at 7:17 PM, Adrian Chadd wrote: >> >> > I'm travelling back to San Jose today; poke me tomorrow and I'll brain >> > dump what I did in ath(4) and the lessons learnt. >> > >> > The TL;DR version - you don't want to grab an extra lock in the >> > read/write paths as that slows things down. Reuse the same per-queue >> > TX/RX lock and have: >> > >> > * a reset flag that is set when something is resetting; that says to >> > the queue "don't bother processing anything, just dive out"; >> > * 'i am doing Tx / Rx' flags per queue that is set at the start of >> > TX/RX servicing and finishes at the end; that way the reset code knows >> > if there's something pending; >> > * have the reset path grab each lock, set the 'reset' flag on each, >> > then walk each queue again and make sure they're all marked as 'not >> > doing TX/RX'. At that point the reset can occur, then the flag cna be >> > cleared, then TX/RX can resume. >> > >> >> so this is slightly different from what Bryan suggested (and you endorsed) >> before, as in that case there was a single 'reset' flag IFF_DRV_RUNNING >> protected by the 'core' lock, then a nested round on all tx and rx locks >> to make sure that all customers have seen it. >> In both cases the tx and rx paths only need the per-queue lock. >> >> As i see it, having a per-queue reset flag removes the need for nesting >> core + queue locks, but since this is only in the control path perhaps >> it is not a big deal (and is better to have a single place to look at to >> tell whether or not we should bail out). >> >> cheers >> luigi >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Mon Aug 5 18:19:06 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A99616D; Mon, 5 Aug 2013 18:19:06 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E01B52E0B; Mon, 5 Aug 2013 18:19:05 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id y10so2694972wgg.4 for ; Mon, 05 Aug 2013 11:19:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=tMzw5Vr38AmxBMmKKa5qf7JQp1ahPyDqUdmn+Y8bX9o=; b=kLNFSK2UD4LQN0lR0UjIMtPl24ZHTSkSmrc1tygIjL6YVaugIqgTKANlwt/lF3/JAX 9Y/P+YmAVyfiAiK0GPX7jXrbCltQSur1i6DbzDTOe7F9Nl4HH9h9i83A9b6ZHrgy+ANY gmqPNqVJ9PmaGtF5Rg4xv/koCVMQRs24rJlDiZmXgYOHaWtfQZh+PDT5ecczOddArxAX qL5y0AMjHdku6E2ADwWLY22DdRxWOUGhvYBUJWcJvMc92Pmu6uVBXEslpM+ZQpMiJrQ1 bW5zb5IXVKRIHx8CvcgVIw+xvA/vcYsXADII5UPeZV0rkgVd7QE2nKlyHBvwmyXQqi23 yyxg== MIME-Version: 1.0 X-Received: by 10.194.201.202 with SMTP id kc10mr14215519wjc.1.1375726744177; Mon, 05 Aug 2013 11:19:04 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Mon, 5 Aug 2013 11:19:04 -0700 (PDT) In-Reply-To: References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> Date: Mon, 5 Aug 2013 11:19:04 -0700 X-Google-Sender-Auth: Ym1h1UimcX5x_7BkjBd_OP4xP4g Message-ID: Subject: Re: [net] protecting interfaces from races between control and data ? From: Adrian Chadd To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD current mailing list , Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri , Jack Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 18:19:06 -0000 No, brian said two things: * the flag, protected by the core lock * per-queue flags -adrian From owner-freebsd-net@FreeBSD.ORG Mon Aug 5 18:46:12 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0DE467CC; Mon, 5 Aug 2013 18:46:12 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7F02A2FCA; Mon, 5 Aug 2013 18:46:11 +0000 (UTC) Received: by mail-vb0-f49.google.com with SMTP id w16so3144326vbb.8 for ; Mon, 05 Aug 2013 11:46:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6afeiJM6qdEqDg7Hhhu2/MbjauYgbQs3h+wtDMDualo=; b=HBU0qqgT82Lik9DbrYsPUPL+n1NQSAjUOy6B6ep2Nil1LdKMn94bXEfQAsqotv6bhR 7TWcrJePREOODMfQu8dULYCTb1dIOQ9oUfL0ryqc8xfaiY7d0Hxdy38bi6gRZ7tvRw9V kALV1ZG9MPpuib3rB0C89fxSkzsA6SEfDJNsBbUnMwoc1qBKUSlx8EX4x49JDduMRk3a VKceRQMC7T7uheZUdPqvjEJpoKYr8646y5IRvI2a3Yk1F7myOO01jnHLymdSaTowIeRK bS2XKrQNbS0EVPTenbylxvuQRXDBVbdJxzhbklxVtvAg5lmHxP+uogrqWvSds8QH9Mwh p41w== MIME-Version: 1.0 X-Received: by 10.58.97.238 with SMTP id ed14mr6154605veb.34.1375728370638; Mon, 05 Aug 2013 11:46:10 -0700 (PDT) Received: by 10.220.159.141 with HTTP; Mon, 5 Aug 2013 11:46:10 -0700 (PDT) In-Reply-To: References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> Date: Mon, 5 Aug 2013 11:46:10 -0700 Message-ID: Subject: Re: [net] protecting interfaces from races between control and data ? From: Jack Vogel To: Luigi Rizzo Content-Type: multipart/mixed; boundary=089e013a1666d6e88d04e337b81a X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Adrian Chadd , FreeBSD current mailing list , Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 18:46:12 -0000 --089e013a1666d6e88d04e337b81a Content-Type: text/plain; charset=ISO-8859-1 What do you think about this change? Cheers, Jack On Mon, Aug 5, 2013 at 10:58 AM, Luigi Rizzo wrote: > On Mon, Aug 5, 2013 at 7:49 PM, Jack Vogel wrote: > >> Sigh, this ends up being ugly I'm afraid. I need some time to look at >> code and think about it. >> >> > actually the intel drivers seem in decent shape, > especially if we reuse IFF_DRV_RUNNING as the reset flag > and the core+queue lock in the control path. > > cheers > luigi > > > >> Jack >> >> >> >> On Mon, Aug 5, 2013 at 10:36 AM, Luigi Rizzo wrote: >> >>> On Mon, Aug 5, 2013 at 7:17 PM, Adrian Chadd wrote: >>> >>> > I'm travelling back to San Jose today; poke me tomorrow and I'll brain >>> > dump what I did in ath(4) and the lessons learnt. >>> > >>> > The TL;DR version - you don't want to grab an extra lock in the >>> > read/write paths as that slows things down. Reuse the same per-queue >>> > TX/RX lock and have: >>> > >>> > * a reset flag that is set when something is resetting; that says to >>> > the queue "don't bother processing anything, just dive out"; >>> > * 'i am doing Tx / Rx' flags per queue that is set at the start of >>> > TX/RX servicing and finishes at the end; that way the reset code knows >>> > if there's something pending; >>> > * have the reset path grab each lock, set the 'reset' flag on each, >>> > then walk each queue again and make sure they're all marked as 'not >>> > doing TX/RX'. At that point the reset can occur, then the flag cna be >>> > cleared, then TX/RX can resume. >>> > >>> >>> so this is slightly different from what Bryan suggested (and you >>> endorsed) >>> before, as in that case there was a single 'reset' flag IFF_DRV_RUNNING >>> protected by the 'core' lock, then a nested round on all tx and rx locks >>> to make sure that all customers have seen it. >>> In both cases the tx and rx paths only need the per-queue lock. >>> >>> As i see it, having a per-queue reset flag removes the need for nesting >>> core + queue locks, but since this is only in the control path perhaps >>> it is not a big deal (and is better to have a single place to look at to >>> tell whether or not we should bail out). >>> >>> cheers >>> luigi >>> >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >> >> > > > -- > -----------------------------------------+------------------------------- > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL +39-050-2211611 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -----------------------------------------+------------------------------- > --089e013a1666d6e88d04e337b81a Content-Type: application/octet-stream; name="quiesce.diff" Content-Disposition: attachment; filename="quiesce.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hk012dni0 UHJveHlDaGFpbnMtMy4xIChodHRwOi8vcHJveHljaGFpbnMuc2YubmV0KQpJbmRleDogaXhnYmUu Ywo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09Ci0tLSBpeGdiZS5jCShyZXZpc2lvbiAyNTM5NjUpCisrKyBpeGdiZS5jCSh3 b3JraW5nIGNvcHkpCkBAIC0xMDczLDYgKzEwNzMsNyBAQAogCiAJbXR4X2Fzc2VydCgmYWRhcHRl ci0+Y29yZV9tdHgsIE1BX09XTkVEKTsKIAlJTklUX0RFQlVHT1VUKCJpeGdiZV9pbml0X2xvY2tl ZDogYmVnaW4iKTsKKwlpeGdiZV9xdWllc2NlX3F1ZXVlcyhhZGFwdGVyKTsKIAlody0+YWRhcHRl cl9zdG9wcGVkID0gRkFMU0U7CiAJaXhnYmVfc3RvcF9hZGFwdGVyKGh3KTsKICAgICAgICAgY2Fs bG91dF9zdG9wKCZhZGFwdGVyLT50aW1lcik7CkBAIC0xMzM2LDcgKzEzMzcsMjYgQEAKIAlyZXR1 cm47CiB9CiAKKy8qCisqKiBNYWtlIHN1cmUgYWxsIHF1ZXVlcyBoYXZlIHNlZW4gSUZGX0RSVl9S VU5OSU5HCisqKiBpcyBjbGVhcmVkIGFuZCBzdG9wIHByb2Nlc3NpbmcuCisqLworc3RhdGljIGlu bGluZSB2b2lkCitpeGdiZV9xdWllc2NlX3F1ZXVlcyhzdHJ1Y3QgYWRhcHRlciAqYWRhcHRlcikK K3sKKwlzdHJ1Y3QgaWZuZXQgICAqaWZwID0gYWRhcHRlci0+aWZwOworCXN0cnVjdCB0eF9yaW5n CSp0eHIgPSBhZGFwdGVyLT50eF9yaW5nczsKKwlzdHJ1Y3QgcnhfcmluZyAqcnhyID0gYWRhcHRl ci0+cnhfcmluZ3M7CiAKKwlpZnAtPmlmX2Rydl9mbGFncyAmPSB+SUZGX0RSVl9SVU5OSU5HOwor CWZvciAoaW50IGkgPSAwOyBpIDwgYWRhcHRlci0+bnVtX3F1ZXVlczsgaSsrLCByeHIrKywgdHhy KyspIHsKKwkJSVhHQkVfVFhfTE9DSyh0eHIpOworCQlJWEdCRV9UWF9VTkxPQ0sodHhyKTsKKwkJ SVhHQkVfUlhfTE9DSyhyeHIpOworCQlJWEdCRV9SWF9VTkxPQ0socnhyKTsKKwl9Cit9CisKIC8q CiAqKgogKiogTVNJWCBJbnRlcnJ1cHQgSGFuZGxlcnMgYW5kIFRhc2tsZXRzCg== --089e013a1666d6e88d04e337b81a-- From owner-freebsd-net@FreeBSD.ORG Mon Aug 5 19:33:34 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2118E8C9 for ; Mon, 5 Aug 2013 19:33:34 +0000 (UTC) (envelope-from joemoog@ebureau.com) Received: from internet06.ebureau.com (internet06.ebureau.com [65.127.24.25]) by mx1.freebsd.org (Postfix) with ESMTP id EAE732299 for ; Mon, 5 Aug 2013 19:33:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by internet06.ebureau.com (Postfix) with ESMTP id A8F8737C6177; Mon, 5 Aug 2013 14:33:23 -0500 (CDT) X-Virus-Scanned: amavisd-new at ebureau.com Received: from internet06.ebureau.com ([127.0.0.1]) by localhost (internet06.ebureau.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1nrVzYuschY; Mon, 5 Aug 2013 14:33:20 -0500 (CDT) Received: from nail.office.ebureau.com (nail.office.ebureau.com [10.10.20.23]) by internet06.ebureau.com (Postfix) with ESMTPSA id 7511B37C6104; Mon, 5 Aug 2013 14:32:49 -0500 (CDT) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1786.1\)) Subject: Re: Intel 4-port ethernet adaptor link aggregation issue From: Joe Moog In-Reply-To: <20130801231643.GB94127@funkthat.com> Date: Mon, 5 Aug 2013 14:32:48 -0500 Message-Id: References: <2A0C085A-1AAF-42D7-867B-6CDD1143B4AC@ebureau.com> <20130801231643.GB94127@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1786.1) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net , Ryan Stone X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 19:33:34 -0000 On Aug 1, 2013, at 6:16 PM, John-Mark Gurney wrote: > Joe Moog wrote this message on Thu, Aug 01, 2013 at 17:14 -0500: >> On Aug 1, 2013, at 4:27 PM, Joe Moog wrote: >>=20 >>> On Aug 1, 2013, at 3:55 PM, Ryan Stone wrote: >>>=20 >>>> Have you tried using only two ports, but both from the NIC? My = suspicion would be that the problem is in the lagg's handling of more = than 2 ports rather than the driver, especially given that it is the igb = driver in all cases. >>>=20 >>> Ryan: >>>=20 >>> We have done this successfully with two ports on the NIC, on another = hardware-identical host. That said, it is entirely possible that this is = a shortcoming of lagg.=20 >>>=20 >>> Can you think of any sort of workaround? Our desired implementation = really requires the inclusion of all 4 ports in the lagg. Failing this = we're looking at the likelihood of 10G ethernet, but with that comes = significant overhead, both cost and administration (before anybody tries = to force the cost debate, remember that there are 10G router modules and = 10G-capable distribution switches involved, never mind the cabling and = SFPs -- it's not just a $600 10G card for the host). I'd like to defer = that requirement as long as possible. 4 aggregated gig ports would serve = us perfectly well for the near-term. >>>=20 >>> Thanks >>>=20 >>> Joe >>=20 >> UPDATE: After additional testing, I'm beginning to suspect the igb = driver. With our setup, ifconfig identifies all the ethernet ports as = igb(0-5). I configured igb0 with a single static IP address (say, = 192.168.1.10), and was able to connect to the host administratively. = While connected, I enabled another port as a second standalone port, = again with a unique address (say, 192.168.1.20), and was able to access = the host via that interface as well. The problem arises when we attempt = to similarly add a third interface to the mix -- and it doesn't seem to = matter what interface(s) we use, or in what order we activate them. = Always on the third interface, that third interface fails to respond = despite showing "active" both in ifconfig and on the switch. >=20 > Can you show an ifconfig -au from the host when it fails, and which = was > the third interface that you added? Above, you talk about adding ips = in > the same subnet to different interfaces, which with modern switchs can > cause issues with which port to deliver packets, etc. >=20 > Do you have any firewalling enabled on the host? >=20 There are no firewalls enabled on the host. I don't know that I see the switch as being the weak point in this setup = as we have been very successful multihoming boxes with these switches = for a variety of other purposes. I will collect and forward "ifconfig = -au" output from the host in a couple of days, as we have had to fall = back on the 2-port lagg to get this particular host in service until = such time the 4-port lagg issue can be resolved. We will be setting up = another hardware-identical host in a lab for further testing and info = gathering. Thanks Joe From owner-freebsd-net@FreeBSD.ORG Mon Aug 5 19:46:04 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C3C73E22 for ; Mon, 5 Aug 2013 19:46:04 +0000 (UTC) (envelope-from joemoog@ebureau.com) Received: from internet06.ebureau.com (internet06.ebureau.com [65.127.24.25]) by mx1.freebsd.org (Postfix) with ESMTP id 8C608235F for ; Mon, 5 Aug 2013 19:46:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by internet06.ebureau.com (Postfix) with ESMTP id E467037C69D5 for ; Mon, 5 Aug 2013 14:46:03 -0500 (CDT) X-Virus-Scanned: amavisd-new at ebureau.com Received: from internet06.ebureau.com ([127.0.0.1]) by localhost (internet06.ebureau.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2BeeGJIrglc for ; Mon, 5 Aug 2013 14:46:02 -0500 (CDT) Received: from nail.office.ebureau.com (nail.office.ebureau.com [10.10.20.23]) by internet06.ebureau.com (Postfix) with ESMTPSA id D63F237C69BD for ; Mon, 5 Aug 2013 14:46:02 -0500 (CDT) From: Joe Moog Message-Id: <7973384E-12E7-4C4A-B21D-526CC94F4194@ebureau.com> Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1786.1\)) Subject: Re: Intel 4-port ethernet adaptor link aggregation issue Date: Mon, 5 Aug 2013 14:46:01 -0500 References: To: freebsd-net@freebsd.org In-Reply-To: X-Mailer: Apple Mail (2.1786.1) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 19:46:04 -0000 > Date: Fri, 02 Aug 2013 09:36:30 +0200 > From: Steve Read > To: freebsd-net@freebsd.org > Subject: Re: Intel 4-port ethernet adaptor link aggregation issue > Message-ID: <51FB617E.2090904@netasq.com> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >=20 > On 01.08.2013 20:07, Joe Moog wrote: >> We have an iXsystems 1U server (E5) with an Intel 4-port ethernet NIC = installed, model I350-T4 (manufactured May of 2013). We're trying to = bind the 4 ports on this NIC together into a single lagg port, connected = LACP to a distribution switch (Cisco 4900-series). We are able to = successfully bind the 2 on-board ethernet ports to a single lagg, = however the NIC is not so cooperative. At first we thought we had a bad = NIC, but a replacement has not fixed the issue. We are thinking there = may be a driver limitation with these Intel ethernet NICs when = attempting to bind more than 2 ports to a lagg. >>=20 >> FreeBSD version: >> FreeBSD 9.1-PRERELEASE #0 r244125: Wed Dec 12 11:47:47 CST 2012 >>=20 >> rc.conf: >> # LINK AGGREGATION >> ifconfig_igb2=3D"UP" >> ifconfig_igb3=3D"UP" >> ifconfig_igb4=3D"UP" >> ifconfig_igb5=3D"UP" >> cloned_interfaces=3D"lagg0" >> ifconfig_lagg0=3D"laggproto lacp laggport igb2 laggport igb3 laggport = igb4 laggport igb5" >> ifconfig_lagg0=3D"inet 192.168.1.14 netmask 255.255.255.0" > Am I the only one who noticed that you replaced the value of=20 > $ifconfig_lagg0 that specifies the proto and the ports with one that=20= > specifies just the address? >=20 > Merge the two ifconfig_lagg0 lines into one, and it will work = infinitely=20 > better, or at least no worse. >=20 > ifconfig_lagg0=3D"laggproto lacp laggport igb2 laggport igb3 laggport = igb4 laggport igb5 inet 192.168.1.14 netmask 255.255.255.0" >=20 >=20 > -- Steve >=20 Steve: We have tried the configuration 3 different ways, all taken directly = from examples found in various BSD forums and wikis: 1) Specifying the IP address for the lagg port as seen above (which has = worked with other FreeBSD lagg configs for us) 2) Specifying the IP address in line with the "laggproto" config as = directed above 3) Using the line ipv4_addrs_lagg0=3D"192.168.1.14/24" in place of the = ifconfig_lagg0=3D"inet....." line above Each option yields the same results -- all will work with a 2-port lagg, = but none will enable a lagg with more than 2 ports (igb). FreeBSD = doesn't seem to care which one we use. Thanks Joe From owner-freebsd-net@FreeBSD.ORG Mon Aug 5 19:57:06 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 566741E2 for ; Mon, 5 Aug 2013 19:57:06 +0000 (UTC) (envelope-from rmind@netbsd.org) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4310C23E4 for ; Mon, 5 Aug 2013 19:57:06 +0000 (UTC) Received: from ws (localhost [IPv6:::1]) by mail.netbsd.org (Postfix) with SMTP id F276A14A1A7; Mon, 5 Aug 2013 19:57:04 +0000 (UTC) Date: Mon, 5 Aug 2013 20:56:46 +0100 From: Mindaugas Rasiukevicius To: christos@astron.com (Christos Zoulas) Subject: Re: BPF_MISC+BPF_COP and BPF_COPX In-Reply-To: References: <20130804191310.2FFBB14A152@mail.netbsd.org> <9813E50B-C557-4FE1-BADF-A2CFFCBB8BD7@felyko.com> X-Mailer: mail(1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20130805195704.F276A14A1A7@mail.netbsd.org> Cc: tech-net@netbsd.org, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 19:57:06 -0000 christos@astron.com (Christos Zoulas) wrote: > >> <...> > >> > >> BPF_STMT(BPF_MISC+BPF_COP, 0), /* A <- funcs[0](...) */ > >> > >> typedef uint32_t(*bpf_copfunc_t)(struct mbuf *pkt, > >> uint32_t A, uint32_t *M); > >> > >> int bpf_set_cop(bpf_ctx_t *c, bpf_copfunc_t funcs[], size_t n); > >> > >> <...> > > Well, aside from the consideration that somehow bpf needs to understand > what memory locations the coproc function alters (so that it considers > them initialized), the bigger question is how does the code for those > functions gets loaded and unloaded, and which bpf programs have access to > those functions. This is not really for /dev/bpf. The user would be a kernel subsystem, which would call bpf_filter(9) on a packet (or whatever is stored in the mbuf) itself. As it would provide/control both the byte-code and the coprocessor functions, the calling convention (e.g. callee/caller words in the memory store) would be consistent. Hence the need to adjust bpf_filter() routine to accept struct bpf_ctx which would contain the coprocessor routines. While doing that, I would also like to add support for initialising the memory store words to a custom values. > > christos > -- Mindaugas From owner-freebsd-net@FreeBSD.ORG Mon Aug 5 20:16:24 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0B48EBA8; Mon, 5 Aug 2013 20:16:24 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D13162589; Mon, 5 Aug 2013 20:16:22 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id ev20so2399907lab.36 for ; Mon, 05 Aug 2013 13:16:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=lSm+JfLcdP0pOg5ejSKOsqZcLRzLlSGySgP/NNuIpuE=; b=LT7tsatXzIytu83j92dOevJul3W8LoCbrxwomiOTfHyiifc9Fcye/gUp7SnLXNlvRm HasXXXzQtc3RuBdBn/q80iAC/s2HExE93MaaRJ9DjGeN2Km3Oq8d4siF9rXrorM+Y7AG wXPFyPcLHUuPFl48uXsg3+s5hZ1CBjlCsATKAd0HIVFor6S3y1dBNQPofQhM0kVbCf3W RRfkt3ld2yQOFEyAJBPsWrTmA18MroqimkEY/V+jZzYaxcf0fY6+LzKp7vaUW0Els0l1 UO1JJrgFDRD0XdLJ0vATQKwRtbVUV3/oOJdabeTSlWiYuwXaP0u3sWVTvj8Ce1hHB5CO fIgQ== MIME-Version: 1.0 X-Received: by 10.152.27.227 with SMTP id w3mr8381624lag.84.1375733780601; Mon, 05 Aug 2013 13:16:20 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.200.165 with HTTP; Mon, 5 Aug 2013 13:16:20 -0700 (PDT) In-Reply-To: References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> Date: Mon, 5 Aug 2013 22:16:20 +0200 X-Google-Sender-Auth: LS8qWBypBbsSgv83bL3eP3IuKrY Message-ID: Subject: Re: [net] protecting interfaces from races between control and data ? From: Luigi Rizzo To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD current mailing list , Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri , Jack Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 20:16:24 -0000 On Mon, Aug 5, 2013 at 8:19 PM, Adrian Chadd wrote: > No, brian said two things: > > * the flag, protected by the core lock > * per-queue flags > i see no mentions on per-queue flags on his email. This is the relevant part ------------ What I've done in my drivers is: * Lock the core mutex * Clear IFF_DRV_RUNNING * Lock/unlock each queue's lock The various Rx/Tx queue functions check for IFF_DRV_RUNNING after (re)acquiring their queue lock. See at vtnet_stop_rendezvous() at [1] for an example. [1] http://svnweb.freebsd.org/base/user/bryanv/vtnetmq/sys/dev/virtio/network/if_vtnet.c?revision=252451&view=markup ----------------- > > > > -adrian > -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Mon Aug 5 20:18:26 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DD89FD7C for ; Mon, 5 Aug 2013 20:18:26 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 34CE325BF for ; Mon, 5 Aug 2013 20:18:25 +0000 (UTC) Received: (qmail 46652 invoked from network); 5 Aug 2013 20:57:41 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 5 Aug 2013 20:57:41 -0000 Message-ID: <520006FB.4010202@freebsd.org> Date: Mon, 05 Aug 2013 22:11:39 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Bryan Venteicher Subject: Re: [net] protecting interfaces from races between control and data ? References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> In-Reply-To: <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo , current@freebsd.org, net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 20:18:26 -0000 On 05.08.2013 16:59, Bryan Venteicher wrote: > > > ----- Original Message ----- >> i am slightly unclear of what mechanisms we use to prevent races >> between interface being reconfigured (up/down/multicast setting, etc, >> all causing reinitialization of the rx and tx rings) and >> >> i) packets from the host stack being sent out; >> ii) interrupts from the network card being processed. >> >> I think in the old times IFF_DRV_RUNNING was used for this purpose, >> but now it is not enough. >> Acquiring the "core lock" in the NIC does not seem enough, either, >> because newer drivers, especially multiqueue ones, have per-queue >> rx and tx locks. >> > > What I've done in my drivers is: > * Lock the core mutex > * Clear IFF_DRV_RUNNING > * Lock/unlock each queue's lock > > The various Rx/Tx queue functions check for IFF_DRV_RUNNING after > (re)acquiring their queue lock. See at vtnet_stop_rendezvous() at > [1] for an example. > >> Does anyone know if there is a generic mechanism, or each driver >> reimplements its own way ? >> > > We desperately need a saner ifnet/driver interface. I think andre@ > had some previous work in this area (and additional plans as well?). Yes. I have received a grant from the FF to look at this in depth, evaluate different approaches and to propose an implementation for the whole stack. -- Andre > IMO, there's a lot to like on what DragonflyBSD has done in this area. > > [1] - http://svnweb.freebsd.org/base/user/bryanv/vtnetmq/sys/dev/virtio/network/if_vtnet.c?revision=252451&view=markup > >> thanks >> luigi >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Mon Aug 5 20:23:05 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4C0C8301; Mon, 5 Aug 2013 20:23:05 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 313AF2630; Mon, 5 Aug 2013 20:23:04 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id fq13so2423046lab.39 for ; Mon, 05 Aug 2013 13:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=HYYcpMGp/JYLBrFL02NsZk+b146MTXEg1cQPplrFqPI=; b=tooPMRzea4HMOktJekdye0HM9KRKrxFRIN968Dtk5xkvdnjAZHxnp+GmjU7ZBYGyPr BLWzD/hcFZdnPXgHFUSTDK39MOfu6ULZwerI6aJQt41WEhM/Sw1LWJx0Bck74Z1+CM3y nhQ3A4j6BYI8VQg2UA0Cc+XIgV6E2/3gR6EAdWBtKijVvPByvNUngj7r2RsoynI7DBZ6 ERfDBvjvoLMkDBMFdGODG1UaUQnltSkNUsfwbtjvk+8JnTLfg2vRvkpvlufAyIy5Njh0 SgQULvXK1/8olwd1NDxSAUd0GT27FOfFTrn9WnI0KVk1go2vrCYBYkb/OU68gjanH4oU pBjg== MIME-Version: 1.0 X-Received: by 10.112.5.199 with SMTP id u7mr9634813lbu.67.1375734182140; Mon, 05 Aug 2013 13:23:02 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.200.165 with HTTP; Mon, 5 Aug 2013 13:23:02 -0700 (PDT) In-Reply-To: References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> Date: Mon, 5 Aug 2013 22:23:02 +0200 X-Google-Sender-Auth: R1Vl7ShBkSaL0gyIsijJhuAdlC0 Message-ID: Subject: Re: [net] protecting interfaces from races between control and data ? From: Luigi Rizzo To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Adrian Chadd , FreeBSD current mailing list , Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 20:23:05 -0000 On Mon, Aug 5, 2013 at 8:46 PM, Jack Vogel wrote: > What do you think about this change? > > looks good to me. but there is no need to rush, especially it will be nice if all interested parties agree on an approach and possibly even naming. I do not have any specific test case but the problem came up when an interface is in netmap mode and dispatches to the in-kernel VALE switch, and userland tries to move the interface back to regular mode. cheers luigi From owner-freebsd-net@FreeBSD.ORG Mon Aug 5 21:01:54 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4676238C; Mon, 5 Aug 2013 21:01:54 +0000 (UTC) (envelope-from bryanv@daemoninthecloset.org) Received: from torment.daemoninthecloset.org (torment.daemoninthecloset.org [94.242.209.234]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F13EA27F2; Mon, 5 Aug 2013 21:01:53 +0000 (UTC) Received: from sage.daemoninthecloset.org (unknown [70.114.209.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sage.daemoninthecloset.org", Issuer "daemoninthecloset.org" (verified OK)) by torment.daemoninthecloset.org (Postfix) with ESMTPS id 5C61442C082F; Mon, 5 Aug 2013 23:06:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemoninthecloset.org X-Virus-Scanned: amavisd-new at daemoninthecloset.org Date: Mon, 5 Aug 2013 16:01:43 -0500 (CDT) From: Bryan Venteicher To: Luigi Rizzo Message-ID: <235239368.957.1375736503264.JavaMail.root@daemoninthecloset.org> In-Reply-To: References: <20130805082307.GA35162@onelab2.iet.unipi.it> <51FFDD1E.1000206@FreeBSD.org> Subject: Re: [net] protecting interfaces from races between control and data ? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.51.1.6] X-Mailer: Zimbra 8.0.2_GA_5569 (ZimbraWebClient - GC28 (Mac)/8.0.2_GA_5569) Thread-Topic: protecting interfaces from races between control and data ? Thread-Index: zrOts6xhU4hMZifeaT65P3z9acX4Vg== Cc: Adrian Chadd , FreeBSD current mailing list , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri , Jack Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 21:01:54 -0000 ----- Original Message ----- > On Mon, Aug 5, 2013 at 8:19 PM, Adrian Chadd wrote: > > > No, brian said two things: > > > > * the flag, protected by the core lock > > * per-queue flags > > > > i see no mentions on per-queue flags on his email. > This is the relevant part > Right, I just use the IFF_DRV_RUNNING flag. I think Adrian meant 'per-queue locks' here? > ------------ > > What I've done in my drivers is: > * Lock the core mutex > * Clear IFF_DRV_RUNNING > * Lock/unlock each queue's lock > > The various Rx/Tx queue functions check for IFF_DRV_RUNNING after > (re)acquiring their queue lock. See at vtnet_stop_rendezvous() at > [1] for an example. > > [1] > http://svnweb.freebsd.org/base/user/bryanv/vtnetmq/sys/dev/virtio/network/if_vtnet.c?revision=252451&view=markup > > ----------------- > > > > > > > > > > -adrian > > > > > > -- > -----------------------------------------+------------------------------- > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL +39-050-2211611 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -----------------------------------------+------------------------------- > From owner-freebsd-net@FreeBSD.ORG Mon Aug 5 21:04:55 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C254855F for ; Mon, 5 Aug 2013 21:04:55 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F3E232823 for ; Mon, 5 Aug 2013 21:04:54 +0000 (UTC) Received: (qmail 46896 invoked from network); 5 Aug 2013 21:50:50 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 5 Aug 2013 21:50:50 -0000 Message-ID: <5200136C.8000201@freebsd.org> Date: Mon, 05 Aug 2013 23:04:44 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: [net] protecting interfaces from races between control and data ? References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , current@freebsd.org, Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 21:04:55 -0000 On 05.08.2013 19:36, Luigi Rizzo wrote: > On Mon, Aug 5, 2013 at 7:17 PM, Adrian Chadd wrote: > >> I'm travelling back to San Jose today; poke me tomorrow and I'll brain >> dump what I did in ath(4) and the lessons learnt. >> >> The TL;DR version - you don't want to grab an extra lock in the >> read/write paths as that slows things down. Reuse the same per-queue >> TX/RX lock and have: >> >> * a reset flag that is set when something is resetting; that says to >> the queue "don't bother processing anything, just dive out"; >> * 'i am doing Tx / Rx' flags per queue that is set at the start of >> TX/RX servicing and finishes at the end; that way the reset code knows >> if there's something pending; >> * have the reset path grab each lock, set the 'reset' flag on each, >> then walk each queue again and make sure they're all marked as 'not >> doing TX/RX'. At that point the reset can occur, then the flag cna be >> cleared, then TX/RX can resume. >> [picking a post at random to reply in this thread] > so this is slightly different from what Bryan suggested (and you endorsed) > before, as in that case there was a single 'reset' flag IFF_DRV_RUNNING > protected by the 'core' lock, then a nested round on all tx and rx locks > to make sure that all customers have seen it. > In both cases the tx and rx paths only need the per-queue lock. > > As i see it, having a per-queue reset flag removes the need for nesting > core + queue locks, but since this is only in the control path perhaps > it is not a big deal (and is better to have a single place to look at to > tell whether or not we should bail out). Ideally we don't want to have any locks in the RX and TX path at all. For the TX path this is not easy to achieve but for RX it isn't difficult at all provided the correct model is used. My upcoming stack/driver proposal is along these lines: RX with MSI-X: Every queue has its own separate RX interrupt vector which is serviced by a single dedicated ithread (or taskqueue) which does while(1) for work on the RX ring only going to sleep when it reaches the end of work on the ring. It is then woken up by an interrupt to resume work. To prevent a live-lock on the CPU it would periodically yield to allow other kernel and user-space threads to run in between. Each queue's ithread (taskqueue) can be pinned to a particular core or float with a certain stickiness. To reconfigure the card (when the RX ring is affected) the ithread (taskqueue) is terminated and after the changes restarted again. This is done by the control path and allows us to run RX completely lock free because there is only ever one ithread accessing the RX queue doing away with the need for further locking synchronization. RX with MSI or legacy interrupts: Here multi-queue is impeded because of some synchronization issues. Depending on the hardware synchronization model the ithreads again do while(1) but have to be made runnable by the interrupt handler when new work has been indicated. TX in general: This is a bit more tricky as we have the hard requirement of packet ordering for individual sessions (tcp and others). That means we must use the same queue for all packets of the same session. This makes running TX non-locked a bit tricky because when we pin a TX queue to a core we must switch to that core first before adding anything to the queue. If the packet was generated on that core there is no overhead, OTOH if not there is the scheduler over- head and some cache losses. Ensuring that a the entire TX path, possibly including user-space (write et al) happens on the same core is difficult and may have its own inefficiencies. The number of TX queue vs. number of cores is another point of contention. To make the 1:1 scheme work well, one must have as many queues as cores. A more scalable and generic approach doesn't bind TX queues to any particular core and is covers each by its own lock to protect the TX ring enqueue. To prevent false lock cache line sharing each TX structure should be on its own cache line. As each session has an affinity hash they become distributed across the TX queues significantly reducing contention. The TX complete handling freeing the mbuf(s) is done the same way as for the RX ring with a dedicated ithread (taskqueue) for each. Also bpf should hook in here (the packet has been sent) instead of at the TX enqueue time. The whole concept of IFF_DRV_RUNNING will go away along with the IFQ macros. Each driver then provides a direct TX function pointer which is put into a decoupled ifnet TX field for use by the stack. Under normal operation all interface TX goes directly into TX DMA ring. The particular multi-queue and locking model is decided by the driver. The kernel provides a couple of common optimized abstractions for use by all drivers that want/need it to avoid code and functionality duplication. When things like ALTQ are activated on an interface the ifnet TX function pointer is replaced with the appropriate intermediate function pointer which eventually will call the drivers TX function. The intermediate TX packet handler (ALTQ) can do its own additional locking on top of the drivers TX locking. Control path: The control path is separate from the high speed TX and RX data paths. It has its own overall lock. Multiple locks typically don't make sense here. If it needs to modify, reconfigure, or newly set up the TX or RX rings then it has to stop the RX ithreads (taskqueues) and to lock the TX queue locks before it can do that. After the changes are made and stable packet processing can continue. I've adjusted / heavily modified fxp, bge and igb drivers in my tcp_workqueue branch to test these concepts. Not all of it is committed or fully up to date. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Aug 5 21:46:23 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A03B46E7 for ; Mon, 5 Aug 2013 21:46:23 +0000 (UTC) (envelope-from rmind@netbsd.org) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 72A4E2A0E for ; Mon, 5 Aug 2013 21:46:23 +0000 (UTC) Received: from ws (localhost [IPv6:::1]) by mail.netbsd.org (Postfix) with SMTP id C000D14A1C3; Mon, 5 Aug 2013 21:46:21 +0000 (UTC) Date: Mon, 5 Aug 2013 22:46:02 +0100 From: Mindaugas Rasiukevicius To: Alexander Nasonov Subject: Re: BPF_MISC+BPF_COP and BPF_COPX In-Reply-To: <20130805203549.GA2241@x1000.localdomain> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <20130805203549.GA2241@x1000.localdomain> X-Mailer: mail(1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20130805214621.C000D14A1C3@mail.netbsd.org> Cc: tech-net@netbsd.org, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 21:46:23 -0000 Hello Alex, Let's keep freebsd-net CCed in case there is any interest. Alexander Nasonov wrote: > > I like the idea but I have some questions: > > 1. Why do you need access to scratch memory? Is your goal to keep a > state for C code between cop calls? In this case, you can use > the standard void* pointer technique. You'd need to define special > getter/setter cop functions and they will be slower than getting/setting > scratch memory but it's more important to keep a very clear separation > between C code and bpf code. You'd also need to pass void* to > bpf_filter(9), of course. Yes, I may want to keep the state in the memory store or pass the arguments through it, since the accumulator might not be enough. If you prefer getter and setter to perform a boundary check and enforce uint32_t type, I am fine with that. Although BPF_MEMWORDS constant and words storing 32-bit values stayed since 80s.. it is not going to change. However, abusing void * is wrong. Once bpf_filter(9) is adjusted to take an opaque struct bpf_ctx *, the memory store ought to be moved into it. > 2. Why do you set X to 0 and 0xffffffff? For the out-of-range access, > all other bpf code aborts filter program with code 0. I think it's > better to keep X unchanged. The rationale behind it is that we might want to handle out-of-range in the byte-code without breaking the flow. This can be a valid case for BPF_COPX. Just BPF_RET 0 seems a limitation, but I do not have a strong feeling here. > 3. Can cop "patch" itself or other cop functions at runtime? It'd be > much safe if an array of cop functions was read-only. As an > additional benefit when using bpfjit, you could generate direct calls > for BPF_COP (but not for BPF_COPX) in bpfjit_generate_code(). Yes, I think coprocessor functions should be read-only once set. And the direct call for BPF_COP when using BPF JIT is very much preferred! > > Alex -- Mindaugas From owner-freebsd-net@FreeBSD.ORG Mon Aug 5 21:48:57 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 79E5D7C7; Mon, 5 Aug 2013 21:48:57 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id C321A2A2A; Mon, 5 Aug 2013 21:48:56 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id E2FC47300A; Mon, 5 Aug 2013 23:53:19 +0200 (CEST) Date: Mon, 5 Aug 2013 23:53:19 +0200 From: Luigi Rizzo To: Andre Oppermann Subject: Re: [net] protecting interfaces from races between control and data ? Message-ID: <20130805215319.GA43271@onelab2.iet.unipi.it> References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> <5200136C.8000201@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5200136C.8000201@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Adrian Chadd , current@freebsd.org, Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 21:48:57 -0000 On Mon, Aug 05, 2013 at 11:04:44PM +0200, Andre Oppermann wrote: > On 05.08.2013 19:36, Luigi Rizzo wrote: ... > > [picking a post at random to reply in this thread] > > tell whether or not we should bail out). > > Ideally we don't want to have any locks in the RX and TX path at all. Ok i have read your proposal below but there are a few things I do not completely understand, below -- essentially I do not understand whether the removal of IFF_DRV_RUNNING (or equivalent) forces you to replace the ifp->new_tx_function() with something else when you want to do an "ifconfig down" Specifically, here are my doubts: - Considering that the rxq lock is rarely contended (only when the control path is active, which in your approach below requires killing and restarting the ithread), and is acquired/released only once per interrupt/batch, i am under the impression that the per-queue RX lock is not a performance problem and makes it easier to reason on the code (and does not require different approach for MSI-x and other cases). - in the tx datapath, do you want to acquire the txq lock before or after calling ifp->new_tx_function() ? (btw how it compares to ifp->if_start or ifp->if_transmit ?) If you do it within the tx handler then you lose the ability of replacing the handler when you do a reconfiguration, because grabbing the tx lock in the control path does not tell you whether anyone is in the handler. If you do it outside, then the driver should also expose the locks, or some locking function. Overall, it seems to me that keeping the IFF_DRV_RUNNING flag is a lot more practical, not to mention fewer modifications to the code. [description of Andre's proposal below, for reference] cheers luigi > Every queue has its own separate RX interrupt vector which is serviced by > a single dedicated ithread (or taskqueue) which does while(1) for work on > the RX ring only going to sleep when it reaches the end of work on the ring. > It is then woken up by an interrupt to resume work. To prevent a live-lock > on the CPU it would periodically yield to allow other kernel and user-space > threads to run in between. Each queue's ithread (taskqueue) can be pinned > to a particular core or float with a certain stickiness. To reconfigure the > card (when the RX ring is affected) the ithread (taskqueue) is terminated > and after the changes restarted again. This is done by the control path > and allows us to run RX completely lock free because there is only ever one > ithread accessing the RX queue doing away with the need for further locking > synchronization. ok I admit i did not think of killing and restarting the ithread, but i wonder how > RX with MSI or legacy interrupts: > > Here multi-queue is impeded because of some synchronization issues. Depending > on the hardware synchronization model the ithreads again do while(1) but have > to be made runnable by the interrupt handler when new work has been indicated. > > TX in general: > > This is a bit more tricky as we have the hard requirement of packet ordering > for individual sessions (tcp and others). That means we must use the same > queue for all packets of the same session. This makes running TX non-locked > a bit tricky because when we pin a TX queue to a core we must switch to that > core first before adding anything to the queue. If the packet was generated > on that core there is no overhead, OTOH if not there is the scheduler over- > head and some cache losses. Ensuring that a the entire TX path, possibly > including user-space (write et al) happens on the same core is difficult and > may have its own inefficiencies. The number of TX queue vs. number of cores > is another point of contention. To make the 1:1 scheme work well, one must > have as many queues as cores. > > A more scalable and generic approach doesn't bind TX queues to any particular > core and is covers each by its own lock to protect the TX ring enqueue. To > prevent false lock cache line sharing each TX structure should be on its own > cache line. As each session has an affinity hash they become distributed > across the TX queues significantly reducing contention. > > The TX complete handling freeing the mbuf(s) is done the same way as for the > RX ring with a dedicated ithread (taskqueue) for each. Also bpf should hook > in here (the packet has been sent) instead of at the TX enqueue time. > > The whole concept of IFF_DRV_RUNNING will go away along with the IFQ macros. > Each driver then provides a direct TX function pointer which is put into a > decoupled ifnet TX field for use by the stack. Under normal operation all > interface TX goes directly into TX DMA ring. The particular multi-queue > and locking model is decided by the driver. The kernel provides a couple > of common optimized abstractions for use by all drivers that want/need it > to avoid code and functionality duplication. When things like ALTQ are > activated on an interface the ifnet TX function pointer is replaced with > the appropriate intermediate function pointer which eventually will call > the drivers TX function. The intermediate TX packet handler (ALTQ) can > do its own additional locking on top of the drivers TX locking. > > Control path: > > The control path is separate from the high speed TX and RX data paths. > It has its own overall lock. Multiple locks typically don't make sense > here. If it needs to modify, reconfigure, or newly set up the TX or RX > rings then it has to stop the RX ithreads (taskqueues) and to lock the > TX queue locks before it can do that. After the changes are made and > stable packet processing can continue. > > I've adjusted / heavily modified fxp, bge and igb drivers in my tcp_workqueue > branch to test these concepts. Not all of it is committed or fully up to date. > > -- > Andre > From owner-freebsd-net@FreeBSD.ORG Tue Aug 6 07:00:19 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CE7F16DB for ; Tue, 6 Aug 2013 07:00:19 +0000 (UTC) (envelope-from alnsn@yandex.ru) Received: from mail.o2.co.uk (vader.london.02.net [82.132.130.150]) by mx1.freebsd.org (Postfix) with ESMTP id 95DBC2BCD for ; Tue, 6 Aug 2013 07:00:18 +0000 (UTC) Received: from localhost (188.29.164.51) by mail.o2.co.uk (8.5.140.03) (authenticated as nasonov) id 51FB540B00C0FF24; Tue, 6 Aug 2013 07:59:10 +0100 Date: Tue, 6 Aug 2013 07:59:03 +0100 From: Alexander Nasonov To: Mindaugas Rasiukevicius Subject: Re: BPF_MISC+BPF_COP and BPF_COPX Message-ID: <20130806065903.GA2835@x1000.localdomain> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <20130805203549.GA2241@x1000.localdomain> <20130805214621.C000D14A1C3@mail.netbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130805214621.C000D14A1C3@mail.netbsd.org> X-Operating-System: Linux 3.4.0 on armv7l X-SHELL: /bin/bash X-FCEDIT: /bin/ed X-EDITOR: /usr/bin/vi X-VISUAL: vim User-Agent: Mutt/1.5.21 (2010-09-15) Cc: tech-net@netbsd.org, freebsd-net@freebsd.org, Alexander Nasonov X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 07:00:19 -0000 Mindaugas Rasiukevicius wrote: > Yes, I may want to keep the state in the memory store or pass the arguments > through it, since the accumulator might not be enough. You have access to a whole packet, why do you need to pass additional arguments through the store? I'm worried about introducing tight coupling between these two very different environments and adding "sugar" for easy interaction is a big step in this direction. > If you prefer getter > and setter to perform a boundary check and enforce uint32_t type, I am fine > with that. Although BPF_MEMWORDS constant and words storing 32-bit values > stayed since 80s.. it is not going to change. > > However, abusing void * is wrong. Once bpf_filter(9) is adjusted to take > an opaque struct bpf_ctx *, the memory store ought to be moved into it. Ah, you plan to generalize scratch memory. It's probably fine but don't generalize too many things because people (me at least) want to be able to recognize the original bpf and its orignal design. Please note that I allocate scratch memory on the stack in bpfjit. If you change scratch memory to be under bpf_ctx, you will need to reimplement quite a lot in bpfjit code. > The rationale behind it is that we might want to handle out-of-range in the > byte-code without breaking the flow. This can be a valid case for BPF_COPX. > Just BPF_RET 0 seems a limitation, but I do not have a strong feeling here. I'd keep it consistent with bpf. Alex From owner-freebsd-net@FreeBSD.ORG Tue Aug 6 07:29:47 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3D464D2E for ; Tue, 6 Aug 2013 07:29:47 +0000 (UTC) (envelope-from sam.gh1986@gmail.com) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BAF672CB2 for ; Tue, 6 Aug 2013 07:29:46 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id eh20so30290lab.33 for ; Tue, 06 Aug 2013 00:29:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=q608yii2mmbrAroqp3lQUjRbdevYvePqMUSqtFRhBnI=; b=FRb/N1P1bWmWQ4n+kssGB6WSnQP0mjV1ZS8TNWXhHpmqr4hGUgEPx2TgAQaB1Obu7X m3JEwNO38RXHHwou4lh0kXHyQAKxdO4p2hi7Iw/yHWHKoeMO/mi/DsfCXiiPk8fV+DHS Oq2ZVRBJVVLmoyXay7KCubNLAKBBAlBDhrm+tuWICWTOhWft8AXlo19Td0mR8AMQsoH5 rBe9LQqYLZO5YzQy79aRuYK8+g7YfdpG4e5Sts1Sp9T4g2kBurOrtuyeRw3uPFbliRuZ 3ULQf3kG1nFhfeDn66Qsl/4IZcpJ/pA/SkvizkFlBQAvxM9Le7HDo4VYqp8LwpqdBBhW Y+hQ== MIME-Version: 1.0 X-Received: by 10.152.9.37 with SMTP id w5mr10360laa.23.1375774184685; Tue, 06 Aug 2013 00:29:44 -0700 (PDT) Received: by 10.112.147.230 with HTTP; Tue, 6 Aug 2013 00:29:44 -0700 (PDT) Date: Tue, 6 Aug 2013 11:59:44 +0430 Message-ID: Subject: how define network with mask 8 for dhcp server? From: s m To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 07:29:47 -0000 hello all, i have a problem with dhcp server. i want to define network with mask 8 and use all network address which are possible. i know it is strange but for some experimental purpose, i want to do it. this is my dhcpd.conf file: subnet 192.0.0.0 netmask 255.0.0.0 { range 192.0.0.1 192.255.255.254; } but dhcp server return core dump and can not work with this configuration. please let me know what is correct configuration in order to use all possible ip addressed in a network with mask 8? thanks in advance, SAM From owner-freebsd-net@FreeBSD.ORG Tue Aug 6 08:03:24 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 419773D8 for ; Tue, 6 Aug 2013 08:03:24 +0000 (UTC) (envelope-from Olivier.Nicole@cs.ait.ac.th) Received: from mail.cs.ait.ac.th (mail.cs.ait.ac.th [192.41.170.16]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E123C2E0C for ; Tue, 6 Aug 2013 08:03:23 +0000 (UTC) Received: from mail.cs.ait.ac.th (localhost [127.0.0.1]) by mail.cs.ait.ac.th (Postfix) with ESMTP id 07132FEBF2; Tue, 6 Aug 2013 14:53:40 +0700 (ICT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.ait.ac.th; h= content-type:content-type:mime-version:message-id:date:date :in-reply-to:subject:subject:from:from:received:received :received; s=selector1; t=1375775619; x=1377590020; bh=gX68Gzal4 Vitx9N38mF6zXKDVUWEYURRtxk+xiyItJ0=; b=kkRd0waiQj0TBahr/okw+3b6P 0AH0cBy4XL5DemT2BM35QHF+tCUm+2naqxhCg6C3rf9vkztAMuV5f0ozjinqPfjx E+sjB/9TH5J+vqU3XqSFTQ3DXUiAJLz62eyVk6K0dH1YUWEjzM1YuIQtzWgTwjKw Llqy8l2L/AGo1JqNc8= X-Virus-Scanned: amavisd-new at cs.ait.ac.th Received: from mail.cs.ait.ac.th ([127.0.0.1]) by mail.cs.ait.ac.th (mail.cs.ait.ac.th [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id QNkDshaHTNs0; Tue, 6 Aug 2013 14:53:39 +0700 (ICT) Received: from banyan.cs.ait.ac.th (banyan.cs.ait.ac.th [192.41.170.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.ait.ac.th (Postfix) with ESMTPS id ACBF6FEBF0; Tue, 6 Aug 2013 14:53:39 +0700 (ICT) Received: (from on@localhost) by banyan.cs.ait.ac.th (8.14.5/8.14.5/Submit) id r767rd8o067221; Tue, 6 Aug 2013 14:53:39 +0700 (ICT) (envelope-from on@banyan.cs.ait.ac.th) From: Olivier Nicole To: s m Subject: Re: how define network with mask 8 for dhcp server? In-Reply-To: (message from s m on Tue, 6 Aug 2013 11:59:44 +0430) Date: Tue, 06 Aug 2013 14:53:39 +0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 08:03:24 -0000 Sam, > subnet 192.0.0.0 netmask 255.0.0.0 I know it is not the answer to your question, but you are wrong in your guess that 192.0.0.0/8 is all private IPs. Only 192.168.0.0/16 is. I know that for certain because my own IP starts with 192. If you want a full /8 private, you can only use 10.0.0.0/8 Bets regards, Olivier -- From owner-freebsd-net@FreeBSD.ORG Tue Aug 6 08:05:39 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 10E2058F for ; Tue, 6 Aug 2013 08:05:39 +0000 (UTC) (envelope-from sam.gh1986@gmail.com) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8B04C2E30 for ; Tue, 6 Aug 2013 08:05:38 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id v1so242088lbd.10 for ; Tue, 06 Aug 2013 01:05:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oXkJ//bDSL/t3SRfvb1z0Ol04ml913q36Om+IbT33LU=; b=P+MT60YA9Ykjib8jNT4saTFWMtdD7+l7OkIDIb45Q6MovYxuLGwTECCUJrkoyiBCLb fz3L2kkr9a35uLvr92QIhK9TM52FUDS2WBceIVu7sXjesn4yz5sGKwGNyZbAmza++9bv XOm1aaOMWHEiTIKE1hc1lWouqnnJmCT+PC8EOW7XSCIoVVU2ULHO5WZOTBZ+pT4mE+Pg VRwc8bBqlWo7xVzHXrNsFyy7+5rmi0spOGyksJ4qQDLX0diuWhZCmJNyU44JGcKg7gPf Uw5fzmQSh0uHT+ApweIV/cWPwUGVtqIGZAb+3/3XCJMGPlOYB31qJUcN6dPfsNcKDELO ocUg== MIME-Version: 1.0 X-Received: by 10.152.6.202 with SMTP id d10mr47845laa.49.1375776336427; Tue, 06 Aug 2013 01:05:36 -0700 (PDT) Received: by 10.112.147.230 with HTTP; Tue, 6 Aug 2013 01:05:36 -0700 (PDT) In-Reply-To: References: Date: Tue, 6 Aug 2013 12:35:36 +0430 Message-ID: Subject: Re: how define network with mask 8 for dhcp server? From: s m To: Olivier Nicole Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 08:05:39 -0000 thanks Olivier, my problem is to know how define a network with mask 8 and dhcp server works correctly with it! you know if i config my dhcpd.conf like below, i have core dump either: subnet 10.0.0.0 netmask 255.0.0.0 { range 10.0.0.1 10.255.255.254; } do you know how should i define my range ?? On Tue, Aug 6, 2013 at 12:23 PM, Olivier Nicole wrote: > Sam, > > > subnet 192.0.0.0 netmask 255.0.0.0 > > I know it is not the answer to your question, but you are wrong in your > guess that 192.0.0.0/8 is all private IPs. Only 192.168.0.0/16 is. > > I know that for certain because my own IP starts with 192. > > If you want a full /8 private, you can only use 10.0.0.0/8 > > Bets regards, > > Olivier > > -- > From owner-freebsd-net@FreeBSD.ORG Tue Aug 6 08:40:11 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2C327D5F for ; Tue, 6 Aug 2013 08:40:11 +0000 (UTC) (envelope-from olivier2553@gmail.com) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E2A2F2FEA for ; Tue, 6 Aug 2013 08:40:10 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id o19so1508266qap.13 for ; Tue, 06 Aug 2013 01:40:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=h5qKyFWlvFWeHD9TWRV9pxmoBt8n31LYisFoYq9Y72U=; b=aOhKpvawsnCeUEr5FI0ubdV3rVT9K8I9cvnb7P47r52f8t3BtMmy1skKf7pYEAdjH3 BF85DUk37P3aLyI4angj1uSGi4OzI/qrkkrq/UG/W4HE+Olc9P6WsF+Qyz4CkUTNh4sp eN2XAdWhzYiBi5tJAOOnhvbY+ZDp2t7RUQT/oCK6Z5sg4hbAlcjrWj8t34SUSWj9TfLo VFawSv1Dxt8dbN3ShlGVErnPkw3zDudbRMDmriCQDHIWqur7a2cn0yCNczMEXS8vjTY3 NcopG11dQ/2npW1gDlSNAdN3Qcn6bCJR6Pi1ga9hHc66tz/Ob80kb9Q8rzBgBRnXHUGB V2WA== MIME-Version: 1.0 X-Received: by 10.224.35.196 with SMTP id q4mr1773570qad.106.1375778409962; Tue, 06 Aug 2013 01:40:09 -0700 (PDT) Sender: olivier2553@gmail.com Received: by 10.49.62.41 with HTTP; Tue, 6 Aug 2013 01:40:09 -0700 (PDT) In-Reply-To: References: Date: Tue, 6 Aug 2013 15:40:09 +0700 X-Google-Sender-Auth: HE54CTkF15X-46xqpiyzrJPrbJU Message-ID: Subject: Re: how define network with mask 8 for dhcp server? From: Olivier Nicole To: s m Content-Type: text/plain; charset=ISO-8859-1 Cc: Olivier Nicole , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 08:40:11 -0000 Sam, > my problem is to know how define a network with mask 8 and dhcp server > works correctly with it! you know if i config my dhcpd.conf like below, i > have core dump either: > subnet 10.0.0.0 netmask 255.0.0.0 > { > range 10.0.0.1 10.255.255.254; > } > > do you know how should i define my range ?? The reason may be that 2^24 machines in a subnet is such a non-sense that dhcp simply cannot manage it. Best regards, Olivier > > On Tue, Aug 6, 2013 at 12:23 PM, Olivier Nicole > wrote: > >> Sam, >> >> > subnet 192.0.0.0 netmask 255.0.0.0 >> >> I know it is not the answer to your question, but you are wrong in your >> guess that 192.0.0.0/8 is all private IPs. Only 192.168.0.0/16 is. >> >> I know that for certain because my own IP starts with 192. >> >> If you want a full /8 private, you can only use 10.0.0.0/8 >> >> Bets regards, >> >> Olivier >> >> -- >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Aug 6 08:59:24 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 07906183 for ; Tue, 6 Aug 2013 08:59:24 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C475F20FF for ; Tue, 6 Aug 2013 08:59:23 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id n10so235932oag.22 for ; Tue, 06 Aug 2013 01:59:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=evpDuc/fOexJkhDjzwatf6Q3F78UfsO7fhSuLhvq4ug=; b=vJVEd9YD4QTVH3BEJL6y8Bt1SMP5DmT5DKm+s/TvO4cKnv8swohqCp8XfKLn9eIiL5 xeY4K4HjHCkwckcvjE8sC6UOOgrhBdFvq1fgZFDxi88/n6eg8/HOFvZt4OyE8+t1VOht pucQkj9/XIjADi6CBHMFv82tIFP0BGcBMzNzmkXGKN8U5BjFOBdZ1QP2xpqbHNbpO23s x6QaHFxFL5Sz1SnXzSybnbldGdAfXIwANdMZtn3Mjq+WmiqvIouzYYZMQ3hkltO4QePh 06/BrEV8vAOixeMuRpI33LfERTSMNGPVGVWna4+wIX3E/nPzGh5hAU1veYX1B+E9aHVz 4Lkg== MIME-Version: 1.0 X-Received: by 10.60.144.230 with SMTP id sp6mr132494oeb.102.1375779562183; Tue, 06 Aug 2013 01:59:22 -0700 (PDT) Received: by 10.76.108.143 with HTTP; Tue, 6 Aug 2013 01:59:22 -0700 (PDT) In-Reply-To: References: Date: Tue, 6 Aug 2013 10:59:22 +0200 Message-ID: Subject: Re: how define network with mask 8 for dhcp server? From: Andreas Nilsson To: Olivier Nicole Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Olivier Nicole , FreeBSD Net , s m X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 08:59:24 -0000 On Tue, Aug 6, 2013 at 10:40 AM, Olivier Nicole wrote: > Sam, > > > my problem is to know how define a network with mask 8 and dhcp server > > works correctly with it! you know if i config my dhcpd.conf like below, i > > have core dump either: > > subnet 10.0.0.0 netmask 255.0.0.0 > > { > > range 10.0.0.1 10.255.255.254; > > } > > > > do you know how should i define my range ?? > > The reason may be that 2^24 machines in a subnet is such a non-sense > that dhcp simply cannot manage it. > > Best regards, > > Olivier > > > > > On Tue, Aug 6, 2013 at 12:23 PM, Olivier Nicole < > Olivier.Nicole@cs.ait.ac.th > >> wrote: > > > >> Sam, > >> > >> > subnet 192.0.0.0 netmask 255.0.0.0 > >> > >> I know it is not the answer to your question, but you are wrong in your > >> guess that 192.0.0.0/8 is all private IPs. Only 192.168.0.0/16 is. > >> > >> I know that for certain because my own IP starts with 192. > >> > >> If you want a full /8 private, you can only use 10.0.0.0/8 > >> > >> Bets regards, > >> > >> Olivier > >> > >> -- > >> > > Well, I would guess it may run out of memory... I did a few tests: 192.0.0.0 - 192.128.255.255 does work ( using ~2.5Gb RAM ). 192.0.0.0 - 192.192.255.255 does work ( using ~4Gb RAM ). 192.0.0.0 - 192.200.255.255 does work ( using ~4.2Gb RAM ). 192.0.0.0 - 192.224.255.255 dumps core Why would you want to have such a huge range? Best regards Andreas From owner-freebsd-net@FreeBSD.ORG Tue Aug 6 09:05:05 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4153C3F1 for ; Tue, 6 Aug 2013 09:05:05 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0993E215A for ; Tue, 6 Aug 2013 09:05:04 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id xn12so215954obc.20 for ; Tue, 06 Aug 2013 02:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c7/a4byIZzijsOoN+Vj8cRUbV3nKAdwtaxlzveoMi+s=; b=MSSEgbSow//Isgv7/awcJhKxI3S8L5B3rGj2hR6YY2arWJGBu1PK9KB+S/HLGBSgyb /dYaFGvomYAS5SlhBPo94S99rycLpj3EUO4HCyCjm4bTp1soaiDCmpYGFn2dlia+d776 y5W9KKIjVDt0YAv3u2d8r0ECzCwWLwsiz806pDIKh8BqpyHd0Cu+wym41IjRxNicN4lv ve8lH1mD260J2UdCd3giA7/l7Uruy6FCvOLG55mAOsslU7Rw8mA63D8QhKtj/Kssq+Ao CS2QAK/NxSSIaFITJRxt99ZwMuuI4bb52AqRL/vOaG+159jLxTBV/Tjv3VermsDUyoCT YBNQ== MIME-Version: 1.0 X-Received: by 10.60.51.41 with SMTP id h9mr229357oeo.49.1375779904196; Tue, 06 Aug 2013 02:05:04 -0700 (PDT) Received: by 10.76.108.143 with HTTP; Tue, 6 Aug 2013 02:05:04 -0700 (PDT) In-Reply-To: References: Date: Tue, 6 Aug 2013 11:05:04 +0200 Message-ID: Subject: Re: how define network with mask 8 for dhcp server? From: Andreas Nilsson To: Olivier Nicole Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Olivier Nicole , FreeBSD Net , s m X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 09:05:05 -0000 On Tue, Aug 6, 2013 at 10:59 AM, Andreas Nilsson wrote: > > > > On Tue, Aug 6, 2013 at 10:40 AM, Olivier Nicole < > olivier.nicole@cs.ait.ac.th> wrote: > >> Sam, >> >> > my problem is to know how define a network with mask 8 and dhcp server >> > works correctly with it! you know if i config my dhcpd.conf like below, >> i >> > have core dump either: >> > subnet 10.0.0.0 netmask 255.0.0.0 >> > { >> > range 10.0.0.1 10.255.255.254; >> > } >> > >> > do you know how should i define my range ?? >> >> The reason may be that 2^24 machines in a subnet is such a non-sense >> that dhcp simply cannot manage it. >> >> Best regards, >> >> Olivier >> >> > >> > On Tue, Aug 6, 2013 at 12:23 PM, Olivier Nicole < >> Olivier.Nicole@cs.ait.ac.th >> >> wrote: >> > >> >> Sam, >> >> >> >> > subnet 192.0.0.0 netmask 255.0.0.0 >> >> >> >> I know it is not the answer to your question, but you are wrong in your >> >> guess that 192.0.0.0/8 is all private IPs. Only 192.168.0.0/16 is. >> >> >> >> I know that for certain because my own IP starts with 192. >> >> >> >> If you want a full /8 private, you can only use 10.0.0.0/8 >> >> >> >> Bets regards, >> >> >> >> Olivier >> >> >> >> -- >> >> >> >> > Well, I would guess it may run out of memory... I did a few tests: > 192.0.0.0 - 192.128.255.255 does work ( using ~2.5Gb RAM ). > 192.0.0.0 - 192.192.255.255 does work ( using ~4Gb RAM ). > 192.0.0.0 - 192.200.255.255 does work ( using ~4.2Gb RAM ). > 192.0.0.0 - 192.224.255.255 dumps core > > Why would you want to have such a huge range? > > Best regards > Andreas > Also, a quick look at the core file gives same indications: #0 0x0000000800c67a21 in _malloc_prefork () from /lib/libc.so.7 #1 0x0000000800c6b72a in malloc () from /lib/libc.so.7 #2 0x000000000047b43b in omapi_object_dereference () #3 0x00000000004844db in do_ip4_hash () #4 0x0000000000484571 in do_ip4_hash () #5 0x0000000000438a45 in pool_timer () #6 0x000000000041dcd7 in trace_conf_stop () #7 0x000000000041fc4e in trace_conf_stop () #8 0x0000000000420698 in trace_conf_stop () #9 0x0000000000420ecc in trace_conf_stop () #10 0x0000000000420197 in trace_conf_stop () #11 0x00000000004247f3 in trace_conf_stop () #12 0x000000000041f210 in trace_conf_stop () #13 0x000000000040f3bf in lease_pinged () #14 0x000000000040d451 in ?? () #15 0x00000008007d7000 in ?? () #16 0x0000000000000000 in ?? () Best regards Andreas From owner-freebsd-net@FreeBSD.ORG Tue Aug 6 09:29:38 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E9787B0F for ; Tue, 6 Aug 2013 09:29:37 +0000 (UTC) (envelope-from sam.gh1986@gmail.com) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 532D0230E for ; Tue, 6 Aug 2013 09:29:37 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id w20so301057lbh.33 for ; Tue, 06 Aug 2013 02:29:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/cBYYwmB/ojZGh/LEsQ28GNeGdlc1JaVtjWLxu/x3ig=; b=v8+pRFcQW4HGTi9a76xNsjRGB4mefyrJb6+6daCaLHnSBvgfUpk7u8JWAoMsT5zBfG 7AyiaQm3gQCQk26zoMndBA5NBHngON0qKNjunYQpHJcA9Yk8HsAlWcrwXXOyH93Ho8Qt AwByNv0LsjY/dldc7RQd6LrKgoYEWQ4bvB/E+8fnwr5CTZkq1CT1J7JoipbnzkzVdESx 1iHjb7KvKGACYQDh5uKeYkS33DHAfIIj4fpdu3b0Azh6VBemiDoLZyywtI79QGpQdkDF 8EcB4Mi7cuRNH3mZl1qWL1eEqRwTM21YJk3avVLF+UhXHrbZ9FEE0bNCdzdr14lAXuWK 1aRg== MIME-Version: 1.0 X-Received: by 10.112.52.100 with SMTP id s4mr816254lbo.64.1375781375164; Tue, 06 Aug 2013 02:29:35 -0700 (PDT) Received: by 10.112.147.230 with HTTP; Tue, 6 Aug 2013 02:29:35 -0700 (PDT) In-Reply-To: References: Date: Tue, 6 Aug 2013 13:59:35 +0430 Message-ID: Subject: Re: how define network with mask 8 for dhcp server? From: s m To: Andreas Nilsson Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Olivier Nicole , FreeBSD Net , Olivier Nicole X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 09:29:38 -0000 thanks Andreas, that's it!!! you know i have user interface program for dhcp. users don't know how dhcp works and just enter desired range in text box. i should handle all entered ranges. in order to do that, i should know how dhcp works with all different ranges and return errors if some ranges is not equivalent like the sample one. so. if i want to have network with mask 8, i should limit my range, right? have you any suggestion what is the maximum range for netmask 8? thanks for your reply again. it clears my mind:) On Tue, Aug 6, 2013 at 1:35 PM, Andreas Nilsson wrote: > > > > On Tue, Aug 6, 2013 at 10:59 AM, Andreas Nilsson wrote: > >> >> >> >> On Tue, Aug 6, 2013 at 10:40 AM, Olivier Nicole < >> olivier.nicole@cs.ait.ac.th> wrote: >> >>> Sam, >>> >>> > my problem is to know how define a network with mask 8 and dhcp server >>> > works correctly with it! you know if i config my dhcpd.conf like >>> below, i >>> > have core dump either: >>> > subnet 10.0.0.0 netmask 255.0.0.0 >>> > { >>> > range 10.0.0.1 10.255.255.254; >>> > } >>> > >>> > do you know how should i define my range ?? >>> >>> The reason may be that 2^24 machines in a subnet is such a non-sense >>> that dhcp simply cannot manage it. >>> >>> Best regards, >>> >>> Olivier >>> >>> > >>> > On Tue, Aug 6, 2013 at 12:23 PM, Olivier Nicole < >>> Olivier.Nicole@cs.ait.ac.th >>> >> wrote: >>> > >>> >> Sam, >>> >> >>> >> > subnet 192.0.0.0 netmask 255.0.0.0 >>> >> >>> >> I know it is not the answer to your question, but you are wrong in >>> your >>> >> guess that 192.0.0.0/8 is all private IPs. Only 192.168.0.0/16 is. >>> >> >>> >> I know that for certain because my own IP starts with 192. >>> >> >>> >> If you want a full /8 private, you can only use 10.0.0.0/8 >>> >> >>> >> Bets regards, >>> >> >>> >> Olivier >>> >> >>> >> -- >>> >> >>> >>> >> Well, I would guess it may run out of memory... I did a few tests: >> 192.0.0.0 - 192.128.255.255 does work ( using ~2.5Gb RAM ). >> 192.0.0.0 - 192.192.255.255 does work ( using ~4Gb RAM ). >> 192.0.0.0 - 192.200.255.255 does work ( using ~4.2Gb RAM ). >> 192.0.0.0 - 192.224.255.255 dumps core >> >> Why would you want to have such a huge range? >> >> Best regards >> Andreas >> > > Also, a quick look at the core file gives same indications: > #0 0x0000000800c67a21 in _malloc_prefork () from /lib/libc.so.7 > #1 0x0000000800c6b72a in malloc () from /lib/libc.so.7 > #2 0x000000000047b43b in omapi_object_dereference () > #3 0x00000000004844db in do_ip4_hash () > #4 0x0000000000484571 in do_ip4_hash () > #5 0x0000000000438a45 in pool_timer () > #6 0x000000000041dcd7 in trace_conf_stop () > #7 0x000000000041fc4e in trace_conf_stop () > #8 0x0000000000420698 in trace_conf_stop () > #9 0x0000000000420ecc in trace_conf_stop () > #10 0x0000000000420197 in trace_conf_stop () > #11 0x00000000004247f3 in trace_conf_stop () > #12 0x000000000041f210 in trace_conf_stop () > #13 0x000000000040f3bf in lease_pinged () > #14 0x000000000040d451 in ?? () > #15 0x00000008007d7000 in ?? () > #16 0x0000000000000000 in ?? () > > Best regards > Andreas > > From owner-freebsd-net@FreeBSD.ORG Tue Aug 6 09:38:36 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 43CE9D48 for ; Tue, 6 Aug 2013 09:38:36 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0A62D2375 for ; Tue, 6 Aug 2013 09:38:35 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id i10so305113oag.30 for ; Tue, 06 Aug 2013 02:38:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EuS3ksO57ooF9LN8Jk0rTdtaF76zca7LVqgL1IhvidA=; b=amM3INeNL1D6irDNSO5yitXv1jlpWvZauCnSbbImFLp9/95RdXgTXnczvdtIW65LQd jT/TZv5ovdxXLjgH6/30TJVL6PN1KeBDsx8BhEc0GjZeRa1LPqR6Yr3AVWJNuFyFhp4Q 1vksu7aQElm2YEx1NtwlDXspfc8+8suaA2nDLX5wKnGq0bT3a2K1oXxF4QQEa2yKK+Zg mOszmwPo13eW2vwWfCJNbtW7lKCmLvh/yGIR1RaA8cGBrpzhdbREMkTr7VbM7ldxuerV MeBBHT8XpOuVCtUq4yHVv7Dr09Mk0muBwULKh1+5691489RjnVHOGRRIhWal8fgyfvgQ nYaw== MIME-Version: 1.0 X-Received: by 10.182.118.129 with SMTP id km1mr366915obb.15.1375781915271; Tue, 06 Aug 2013 02:38:35 -0700 (PDT) Received: by 10.76.108.143 with HTTP; Tue, 6 Aug 2013 02:38:35 -0700 (PDT) In-Reply-To: References: Date: Tue, 6 Aug 2013 11:38:35 +0200 Message-ID: Subject: Re: how define network with mask 8 for dhcp server? From: Andreas Nilsson To: s m Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Olivier Nicole , FreeBSD Net , Olivier Nicole X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 09:38:36 -0000 On Tue, Aug 6, 2013 at 11:29 AM, s m wrote: > thanks Andreas, that's it!!! > you know i have user interface program for dhcp. users don't know how dhcp > works and just enter desired range in text box. i should handle all entered > ranges. in order to do that, i should know how dhcp works with all > different ranges and return errors if some ranges is not equivalent like > the sample one. > Ok. Someone more versed in debugging should probably determine if the crash is in libc or just that dhcp does not handle malloc error. > > so. if i want to have network with mask 8, i should limit my range, right? > have you any suggestion what is the maximum range for netmask 8? > thanks for your reply again. it clears my mind:) > Exactly. I just tried 192.0.0.1-192.220.255.255 which works ( takes ~3 minutes to start, using 4.5gb of ram ) and then 192.0.0.1-192.221.255.255 which segfaults. The machine I test on does have 16gb of ram and 16gb of swap, so there should be a lot more mem available. Best regards Andreas > > > On Tue, Aug 6, 2013 at 1:35 PM, Andreas Nilsson wrote: > >> >> >> >> On Tue, Aug 6, 2013 at 10:59 AM, Andreas Nilsson wrote: >> >>> >>> >>> >>> On Tue, Aug 6, 2013 at 10:40 AM, Olivier Nicole < >>> olivier.nicole@cs.ait.ac.th> wrote: >>> >>>> Sam, >>>> >>>> > my problem is to know how define a network with mask 8 and dhcp server >>>> > works correctly with it! you know if i config my dhcpd.conf like >>>> below, i >>>> > have core dump either: >>>> > subnet 10.0.0.0 netmask 255.0.0.0 >>>> > { >>>> > range 10.0.0.1 10.255.255.254; >>>> > } >>>> > >>>> > do you know how should i define my range ?? >>>> >>>> The reason may be that 2^24 machines in a subnet is such a non-sense >>>> that dhcp simply cannot manage it. >>>> >>>> Best regards, >>>> >>>> Olivier >>>> >>>> > >>>> > On Tue, Aug 6, 2013 at 12:23 PM, Olivier Nicole < >>>> Olivier.Nicole@cs.ait.ac.th >>>> >> wrote: >>>> > >>>> >> Sam, >>>> >> >>>> >> > subnet 192.0.0.0 netmask 255.0.0.0 >>>> >> >>>> >> I know it is not the answer to your question, but you are wrong in >>>> your >>>> >> guess that 192.0.0.0/8 is all private IPs. Only 192.168.0.0/16 is. >>>> >> >>>> >> I know that for certain because my own IP starts with 192. >>>> >> >>>> >> If you want a full /8 private, you can only use 10.0.0.0/8 >>>> >> >>>> >> Bets regards, >>>> >> >>>> >> Olivier >>>> >> >>>> >> -- >>>> >> >>>> >>>> >>> Well, I would guess it may run out of memory... I did a few tests: >>> 192.0.0.0 - 192.128.255.255 does work ( using ~2.5Gb RAM ). >>> 192.0.0.0 - 192.192.255.255 does work ( using ~4Gb RAM ). >>> 192.0.0.0 - 192.200.255.255 does work ( using ~4.2Gb RAM ). >>> 192.0.0.0 - 192.224.255.255 dumps core >>> >>> Why would you want to have such a huge range? >>> >>> Best regards >>> Andreas >>> >> >> Also, a quick look at the core file gives same indications: >> #0 0x0000000800c67a21 in _malloc_prefork () from /lib/libc.so.7 >> #1 0x0000000800c6b72a in malloc () from /lib/libc.so.7 >> #2 0x000000000047b43b in omapi_object_dereference () >> #3 0x00000000004844db in do_ip4_hash () >> #4 0x0000000000484571 in do_ip4_hash () >> #5 0x0000000000438a45 in pool_timer () >> #6 0x000000000041dcd7 in trace_conf_stop () >> #7 0x000000000041fc4e in trace_conf_stop () >> #8 0x0000000000420698 in trace_conf_stop () >> #9 0x0000000000420ecc in trace_conf_stop () >> #10 0x0000000000420197 in trace_conf_stop () >> #11 0x00000000004247f3 in trace_conf_stop () >> #12 0x000000000041f210 in trace_conf_stop () >> #13 0x000000000040f3bf in lease_pinged () >> #14 0x000000000040d451 in ?? () >> #15 0x00000008007d7000 in ?? () >> #16 0x0000000000000000 in ?? () >> >> Best regards >> Andreas >> >> > From owner-freebsd-net@FreeBSD.ORG Tue Aug 6 16:43:58 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1A75DBA8 for ; Tue, 6 Aug 2013 16:43:58 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 49BC52854 for ; Tue, 6 Aug 2013 16:43:57 +0000 (UTC) Received: (qmail 49916 invoked from network); 6 Aug 2013 17:29:43 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 6 Aug 2013 17:29:43 -0000 Message-ID: <520127C3.3020101@freebsd.org> Date: Tue, 06 Aug 2013 18:43:47 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: [net] protecting interfaces from races between control and data ? References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> <5200136C.8000201@freebsd.org> <20130805215319.GA43271@onelab2.iet.unipi.it> In-Reply-To: <20130805215319.GA43271@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , current@freebsd.org, Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 16:43:58 -0000 On 05.08.2013 23:53, Luigi Rizzo wrote: > On Mon, Aug 05, 2013 at 11:04:44PM +0200, Andre Oppermann wrote: >> On 05.08.2013 19:36, Luigi Rizzo wrote: > ... >> >> [picking a post at random to reply in this thread] >>> tell whether or not we should bail out). >> >> Ideally we don't want to have any locks in the RX and TX path at all. > > Ok i have read your proposal below but there are a few things > I do not completely understand, below -- essentially I do not > understand whether the removal of IFF_DRV_RUNNING (or equivalent) > forces you to replace the ifp->new_tx_function() with something > else when you want to do an "ifconfig down" Sorry, it's IFF_DRV_OACTIVE that'll go away, not IFF_DRV_RUNNING. It's of no use with multi-queue anyways. Though we may get more differentiated states for interface availability. > Specifically, here are my doubts: > > - Considering that the rxq lock is rarely contended > (only when the control path is active, which in your approach > below requires killing and restarting the ithread), > and is acquired/released only once per interrupt/batch, > i am under the impression that the per-queue RX lock is > not a performance problem and makes it easier to reason > on the code (and does not require different approach > for MSI-x and other cases). There are two important things here: 1) there must only be one (i)thread per RX queue to prevent lock contention; 2) even with a non-contended lock there are effects felt by the other cores or CPUs like bus lock cycles which are considerable. Stopping and restarting the ithread/taskqueue in those cases that require more involved (hardware) reconfiguration isn't much of an overhead compared to per-packet or per-packet-batch locking in the hot path. > - in the tx datapath, do you want to acquire the txq lock > before or after calling ifp->new_tx_function() ? > (btw how it compares to ifp->if_start or ifp->if_transmit ?) Struct ifnet is going to be split into two parts, the stack owned part and the driver owned part. The stack will never fumble the driver owned parts and the driver must only change the stack owned parts through accessor functions. (This split has also been proposed by Juniper quite some time ago but for different reasons). The driver supplies a TX frame transmit function (mostly like if_transmit today) which does all locking and multi-queue handling internally (driver owned. This gives driver writers the freedom to better adjust to different hardware communication methods as they become available, like we witnessed a couple of times in the past. If the driver is multi-queue capable it takes the rss-hash from the packet header to select an appropriate queue which may have its own dedicated lock. If there is only one queue then it will obtain that lock which may see some contention when multiple cores try to send at the same time. The driver may do more extensive locking, however that likely comes at the expense of performance. Typically on modern NICs the TX function will be a thin locked wrapper around the DMA enqueue function. For or older or other kinds of interfaces it may implement full internal soft queuing (as the IFQ did). An efficient generic implementation of those will be provided for driver to make use of. > If you do it within the tx handler then you lose the ability > of replacing the handler when you do a reconfiguration, > because grabbing the tx lock in the control path does not tell > you whether anyone is in the handler. > If you do it outside, then the driver should also expose the locks, > or some locking function. The stack calls the transmit function without any driver-specific locks held. It'll make sure though that the stack-ifnet doesn't go away in between probably by using cheap rmlocks. The drivers control path gets a function to ensure that the stack has drained all writers and it is safe to reconfigure (as in callout_drain()). Not all hardware and control path changes necessarily require a reinitialization. The stack-ifnet shadows some information, like interface state, and may do its own independent SMP optimizations to avoid contention. > Overall, it seems to me that keeping the IFF_DRV_RUNNING > flag is a lot more practical, not to mention fewer modifications > to the code. Generally we want to optimize for the fast packet path, reduce any friction we can, and take a hit on reconfig being more "expensive" as it is much less frequent. Mind you not all of this is worked out in detail yet and may be subject to further changes and refinements as more benchmarking of different approaches is performed. -- Andre [PS: I'm currently on summer vacation and write this while having access] > [description of Andre's proposal below, for reference] > > cheers > luigi > >> Every queue has its own separate RX interrupt vector which is serviced by >> a single dedicated ithread (or taskqueue) which does while(1) for work on >> the RX ring only going to sleep when it reaches the end of work on the ring. >> It is then woken up by an interrupt to resume work. To prevent a live-lock >> on the CPU it would periodically yield to allow other kernel and user-space >> threads to run in between. Each queue's ithread (taskqueue) can be pinned >> to a particular core or float with a certain stickiness. To reconfigure the >> card (when the RX ring is affected) the ithread (taskqueue) is terminated >> and after the changes restarted again. This is done by the control path >> and allows us to run RX completely lock free because there is only ever one >> ithread accessing the RX queue doing away with the need for further locking >> synchronization. > > ok I admit i did not think of killing and restarting the ithread, > but i wonder how >> RX with MSI or legacy interrupts: >> >> Here multi-queue is impeded because of some synchronization issues. Depending >> on the hardware synchronization model the ithreads again do while(1) but have >> to be made runnable by the interrupt handler when new work has been indicated. >> >> TX in general: >> >> This is a bit more tricky as we have the hard requirement of packet ordering >> for individual sessions (tcp and others). That means we must use the same >> queue for all packets of the same session. This makes running TX non-locked >> a bit tricky because when we pin a TX queue to a core we must switch to that >> core first before adding anything to the queue. If the packet was generated >> on that core there is no overhead, OTOH if not there is the scheduler over- >> head and some cache losses. Ensuring that a the entire TX path, possibly >> including user-space (write et al) happens on the same core is difficult and >> may have its own inefficiencies. The number of TX queue vs. number of cores >> is another point of contention. To make the 1:1 scheme work well, one must >> have as many queues as cores. >> >> A more scalable and generic approach doesn't bind TX queues to any particular >> core and is covers each by its own lock to protect the TX ring enqueue. To >> prevent false lock cache line sharing each TX structure should be on its own >> cache line. As each session has an affinity hash they become distributed >> across the TX queues significantly reducing contention. >> >> The TX complete handling freeing the mbuf(s) is done the same way as for the >> RX ring with a dedicated ithread (taskqueue) for each. Also bpf should hook >> in here (the packet has been sent) instead of at the TX enqueue time. >> >> The whole concept of IFF_DRV_RUNNING will go away along with the IFQ macros. >> Each driver then provides a direct TX function pointer which is put into a >> decoupled ifnet TX field for use by the stack. Under normal operation all >> interface TX goes directly into TX DMA ring. The particular multi-queue >> and locking model is decided by the driver. The kernel provides a couple >> of common optimized abstractions for use by all drivers that want/need it >> to avoid code and functionality duplication. When things like ALTQ are >> activated on an interface the ifnet TX function pointer is replaced with >> the appropriate intermediate function pointer which eventually will call >> the drivers TX function. The intermediate TX packet handler (ALTQ) can >> do its own additional locking on top of the drivers TX locking. >> >> Control path: >> >> The control path is separate from the high speed TX and RX data paths. >> It has its own overall lock. Multiple locks typically don't make sense >> here. If it needs to modify, reconfigure, or newly set up the TX or RX >> rings then it has to stop the RX ithreads (taskqueues) and to lock the >> TX queue locks before it can do that. After the changes are made and >> stable packet processing can continue. >> >> I've adjusted / heavily modified fxp, bge and igb drivers in my tcp_workqueue >> branch to test these concepts. Not all of it is committed or fully up to date. >> >> -- >> Andre >> > > From owner-freebsd-net@FreeBSD.ORG Tue Aug 6 22:55:43 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 90825B9F; Tue, 6 Aug 2013 22:55:43 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 002AE2957; Tue, 6 Aug 2013 22:55:41 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id eh20so742602lab.19 for ; Tue, 06 Aug 2013 15:55:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qS39UwrZbO6GBzSgTi/tEiqoEzpCy/+oszbaWnu6jlM=; b=D0G/WC1+bKvlGwGryXpLFFoX7FSVEaSimjckU1TV0zjA4GPaIiWQHOlFZf/aRjDzqq vyM+ayqJzGFg2Qoks4a5it3K+sAJajJqiQzToUuGC2Ax3xYdTF+8Qzd/ALkp2Ntmqh3w 6Nkp7NIWOPAIIDL7ZKoiZ6yTAEUxp0ro9Kvyr6PRq+2ei4xmZOdzV/uFHSs2QbBOwzbL FG7j7eoT63n9nBm2Qlf3UwKIBGE/y8XUcwf8oVPMRt7+K2UXWDblR3bA8HN3PxWHYAkh ipknG4ApY6io8XXHIaujZI1dUrL0971lw4DUyxQeJaVuTx0TBz9IxA8Wt8cXO+HO/mOn PZ2w== MIME-Version: 1.0 X-Received: by 10.112.134.202 with SMTP id pm10mr423807lbb.79.1375829739818; Tue, 06 Aug 2013 15:55:39 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.200.165 with HTTP; Tue, 6 Aug 2013 15:55:39 -0700 (PDT) In-Reply-To: <520127C3.3020101@freebsd.org> References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> <5200136C.8000201@freebsd.org> <20130805215319.GA43271@onelab2.iet.unipi.it> <520127C3.3020101@freebsd.org> Date: Wed, 7 Aug 2013 00:55:39 +0200 X-Google-Sender-Auth: jbbZQ-QJDDC23Bo6q3t8fnY-dD0 Message-ID: Subject: Re: [net] protecting interfaces from races between control and data ? From: Luigi Rizzo To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Adrian Chadd , current@freebsd.org, Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 22:55:43 -0000 thanks for the explanations and for experimenting with the various alternatives. I started this thread just to understand whether something was already in place, and to make sure that what I do with netmap is not worse than the situation we have now. I guess that while the best solution comes out, a quick and non intrusive workaround is at least follow the approach that Bryan suggested. cheers luigi On Tue, Aug 6, 2013 at 6:43 PM, Andre Oppermann wrote: > On 05.08.2013 23:53, Luigi Rizzo wrote: > >> On Mon, Aug 05, 2013 at 11:04:44PM +0200, Andre Oppermann wrote: >> >>> On 05.08.2013 19:36, Luigi Rizzo wrote: >>> >> ... >> >>> >>> [picking a post at random to reply in this thread] >>> >>>> tell whether or not we should bail out). >>>> >>> >>> Ideally we don't want to have any locks in the RX and TX path at all. >>> >> >> Ok i have read your proposal below but there are a few things >> I do not completely understand, below -- essentially I do not >> understand whether the removal of IFF_DRV_RUNNING (or equivalent) >> forces you to replace the ifp->new_tx_function() with something >> else when you want to do an "ifconfig down" >> > > Sorry, it's IFF_DRV_OACTIVE that'll go away, not IFF_DRV_RUNNING. > It's of no use with multi-queue anyways. Though we may get more > differentiated states for interface availability. > > > Specifically, here are my doubts: >> >> - Considering that the rxq lock is rarely contended >> (only when the control path is active, which in your approach >> below requires killing and restarting the ithread), >> and is acquired/released only once per interrupt/batch, >> i am under the impression that the per-queue RX lock is >> not a performance problem and makes it easier to reason >> on the code (and does not require different approach >> for MSI-x and other cases). >> > > There are two important things here: 1) there must only be one > (i)thread per RX queue to prevent lock contention; 2) even with > a non-contended lock there are effects felt by the other cores > or CPUs like bus lock cycles which are considerable. Stopping > and restarting the ithread/taskqueue in those cases that require > more involved (hardware) reconfiguration isn't much of an overhead > compared to per-packet or per-packet-batch locking in the hot path. > > > - in the tx datapath, do you want to acquire the txq lock >> before or after calling ifp->new_tx_function() ? >> (btw how it compares to ifp->if_start or ifp->if_transmit ?) >> > > Struct ifnet is going to be split into two parts, the stack owned > part and the driver owned part. The stack will never fumble the > driver owned parts and the driver must only change the stack owned > parts through accessor functions. (This split has also been proposed > by Juniper quite some time ago but for different reasons). > > The driver supplies a TX frame transmit function (mostly like if_transmit > today) which does all locking and multi-queue handling internally (driver > owned. This gives driver writers the freedom to better adjust to different > hardware communication methods as they become available, like we witnessed > a couple of times in the past. > > If the driver is multi-queue capable it takes the rss-hash from the packet > header > to select an appropriate queue which may have its own dedicated lock. If > there > is only one queue then it will obtain that lock which may see some > contention > when multiple cores try to send at the same time. The driver may do more > extensive locking, however that likely comes at the expense of performance. > > Typically on modern NICs the TX function will be a thin locked wrapper > around > the DMA enqueue function. For or older or other kinds of interfaces it may > implement full internal soft queuing (as the IFQ did). An efficient > generic > implementation of those will be provided for driver to make use of. > > > > If you do it within the tx handler then you lose the ability > > of replacing the handler when you do a reconfiguration, > > because grabbing the tx lock in the control path does not tell > > you whether anyone is in the handler. > > If you do it outside, then the driver should also expose the locks, > > or some locking function. > > The stack calls the transmit function without any driver-specific locks > held. > It'll make sure though that the stack-ifnet doesn't go away in between > probably > by using cheap rmlocks. > > The drivers control path gets a function to ensure that the stack has > drained > all writers and it is safe to reconfigure (as in callout_drain()). Not all > hardware and control path changes necessarily require a reinitialization. > > The stack-ifnet shadows some information, like interface state, and may do > its > own independent SMP optimizations to avoid contention. > > > Overall, it seems to me that keeping the IFF_DRV_RUNNING >> flag is a lot more practical, not to mention fewer modifications >> to the code. >> > > Generally we want to optimize for the fast packet path, reduce any > friction we > can, and take a hit on reconfig being more "expensive" as it is much less > frequent. > > Mind you not all of this is worked out in detail yet and may be subject to > further changes and refinements as more benchmarking of different > approaches > is performed. > > -- > Andre > > [PS: I'm currently on summer vacation and write this while having access] > > > [description of Andre's proposal below, for reference] >> >> cheers >> luigi >> >> Every queue has its own separate RX interrupt vector which is serviced by >>> a single dedicated ithread (or taskqueue) which does while(1) for work on >>> the RX ring only going to sleep when it reaches the end of work on the >>> ring. >>> It is then woken up by an interrupt to resume work. To prevent a >>> live-lock >>> on the CPU it would periodically yield to allow other kernel and >>> user-space >>> threads to run in between. Each queue's ithread (taskqueue) can be >>> pinned >>> to a particular core or float with a certain stickiness. To reconfigure >>> the >>> card (when the RX ring is affected) the ithread (taskqueue) is terminated >>> and after the changes restarted again. This is done by the control path >>> and allows us to run RX completely lock free because there is only ever >>> one >>> ithread accessing the RX queue doing away with the need for further >>> locking >>> synchronization. >>> >> >> ok I admit i did not think of killing and restarting the ithread, >> but i wonder how >> >>> RX with MSI or legacy interrupts: >>> >>> Here multi-queue is impeded because of some synchronization issues. >>> Depending >>> on the hardware synchronization model the ithreads again do while(1) but >>> have >>> to be made runnable by the interrupt handler when new work has been >>> indicated. >>> >>> TX in general: >>> >>> This is a bit more tricky as we have the hard requirement of packet >>> ordering >>> for individual sessions (tcp and others). That means we must use the >>> same >>> queue for all packets of the same session. This makes running TX >>> non-locked >>> a bit tricky because when we pin a TX queue to a core we must switch to >>> that >>> core first before adding anything to the queue. If the packet was >>> generated >>> on that core there is no overhead, OTOH if not there is the scheduler >>> over- >>> head and some cache losses. Ensuring that a the entire TX path, possibly >>> including user-space (write et al) happens on the same core is difficult >>> and >>> may have its own inefficiencies. The number of TX queue vs. number of >>> cores >>> is another point of contention. To make the 1:1 scheme work well, one >>> must >>> have as many queues as cores. >>> >>> A more scalable and generic approach doesn't bind TX queues to any >>> particular >>> core and is covers each by its own lock to protect the TX ring enqueue. >>> To >>> prevent false lock cache line sharing each TX structure should be on its >>> own >>> cache line. As each session has an affinity hash they become distributed >>> across the TX queues significantly reducing contention. >>> >>> The TX complete handling freeing the mbuf(s) is done the same way as for >>> the >>> RX ring with a dedicated ithread (taskqueue) for each. Also bpf should >>> hook >>> in here (the packet has been sent) instead of at the TX enqueue time. >>> >>> The whole concept of IFF_DRV_RUNNING will go away along with the IFQ >>> macros. >>> Each driver then provides a direct TX function pointer which is put into >>> a >>> decoupled ifnet TX field for use by the stack. Under normal operation >>> all >>> interface TX goes directly into TX DMA ring. The particular multi-queue >>> and locking model is decided by the driver. The kernel provides a couple >>> of common optimized abstractions for use by all drivers that want/need it >>> to avoid code and functionality duplication. When things like ALTQ are >>> activated on an interface the ifnet TX function pointer is replaced with >>> the appropriate intermediate function pointer which eventually will call >>> the drivers TX function. The intermediate TX packet handler (ALTQ) can >>> do its own additional locking on top of the drivers TX locking. >>> >>> Control path: >>> >>> The control path is separate from the high speed TX and RX data paths. >>> It has its own overall lock. Multiple locks typically don't make sense >>> here. If it needs to modify, reconfigure, or newly set up the TX or RX >>> rings then it has to stop the RX ithreads (taskqueues) and to lock the >>> TX queue locks before it can do that. After the changes are made and >>> stable packet processing can continue. >>> >>> I've adjusted / heavily modified fxp, bge and igb drivers in my >>> tcp_workqueue >>> branch to test these concepts. Not all of it is committed or fully up >>> to date. >>> >>> -- >>> Andre >>> >>> >> >> > -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Wed Aug 7 01:42:50 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 52BCA594; Wed, 7 Aug 2013 01:42:50 +0000 (UTC) (envelope-from markj@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 28DD02EA0; Wed, 7 Aug 2013 01:42:50 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r771gogh026175; Wed, 7 Aug 2013 01:42:50 GMT (envelope-from markj@freefall.freebsd.org) Received: (from markj@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r771gnP2026174; Wed, 7 Aug 2013 01:42:49 GMT (envelope-from markj) Date: Wed, 7 Aug 2013 01:42:49 GMT Message-Id: <201308070142.r771gnP2026174@freefall.freebsd.org> To: anarcat@koumbit.org, markj@FreeBSD.org, freebsd-net@FreeBSD.org From: markj@FreeBSD.org Subject: Re: kern/179975: [igb] igb(4) fails to do polling(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 01:42:50 -0000 Synopsis: [igb] igb(4) fails to do polling(4) State-Changed-From-To: patched->closed State-Changed-By: markj State-Changed-When: Wed Aug 7 01:42:49 UTC 2013 State-Changed-Why: Submitter reported that they haven't had any problems since applying the patch. http://www.freebsd.org/cgi/query-pr.cgi?pr=179975 From owner-freebsd-net@FreeBSD.ORG Wed Aug 7 06:37:06 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CF88E873 for ; Wed, 7 Aug 2013 06:37:06 +0000 (UTC) (envelope-from sam.gh1986@gmail.com) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3A0402A51 for ; Wed, 7 Aug 2013 06:37:06 +0000 (UTC) Received: by mail-lb0-f181.google.com with SMTP id o10so1202464lbi.26 for ; Tue, 06 Aug 2013 23:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KLFa0nwRqvJjyGZUxLljxNvU+e8zZdrP4kFk9i1PTZo=; b=nv07RrpGkOnmYi+p4hCbs7BWm3f374bb+ZH3aCdiHW3C4tq6A3TJ42Zkd+shH2zzNj QPQjOF5ZoU0dIAtBCYT+A4icdMq2EXP/ryJXX/K/llk/Hs5+rqfJ2o2ZVx86shiqD5gO 0NNb7pQN6Hx7aDS3svB4x9U4G3uEgEnlbg64Wy+i6f1XyhCV9Vz76fcc6x+qVFTVbbke mf/UOXJtQPcsxvu9mw0Y/4k9RnRz9K9Vtq9MQQv1d9QsZER5cKnXfgbve0uFcKd06L8b bP8fEpdhb7GD+092ywgvM2CKZFnEe6vFzceOiV9hqhr79ReJM+iGyZSIbm2SWxAW5EG3 /hPw== MIME-Version: 1.0 X-Received: by 10.152.9.37 with SMTP id w5mr743882laa.23.1375857423993; Tue, 06 Aug 2013 23:37:03 -0700 (PDT) Received: by 10.112.147.230 with HTTP; Tue, 6 Aug 2013 23:37:03 -0700 (PDT) In-Reply-To: References: Date: Wed, 7 Aug 2013 11:07:03 +0430 Message-ID: Subject: Re: how define network with mask 8 for dhcp server? From: s m To: Andreas Nilsson Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Olivier Nicole , FreeBSD Net , Olivier Nicole X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 06:37:06 -0000 yes, i solved my problem. thanks every body for your answers. it help me a lot. SAM On Tue, Aug 6, 2013 at 2:08 PM, Andreas Nilsson wrote: > > > > On Tue, Aug 6, 2013 at 11:29 AM, s m wrote: > >> thanks Andreas, that's it!!! >> you know i have user interface program for dhcp. users don't know how >> dhcp works and just enter desired range in text box. i should handle all >> entered ranges. in order to do that, i should know how dhcp works with all >> different ranges and return errors if some ranges is not equivalent like >> the sample one. >> > > Ok. Someone more versed in debugging should probably determine if the > crash is in libc or just that dhcp does not handle malloc error. > > >> >> so. if i want to have network with mask 8, i should limit my range, >> right? have you any suggestion what is the maximum range for netmask 8? >> thanks for your reply again. it clears my mind:) >> > > Exactly. > > I just tried > 192.0.0.1-192.220.255.255 which works ( takes ~3 minutes to start, using > 4.5gb of ram ) > and then > 192.0.0.1-192.221.255.255 which segfaults. > > The machine I test on does have 16gb of ram and 16gb of swap, so there > should be a lot more mem available. > > Best regards > Andreas > >> >> >> On Tue, Aug 6, 2013 at 1:35 PM, Andreas Nilsson wrote: >> >>> >>> >>> >>> On Tue, Aug 6, 2013 at 10:59 AM, Andreas Nilsson wrote: >>> >>>> >>>> >>>> >>>> On Tue, Aug 6, 2013 at 10:40 AM, Olivier Nicole < >>>> olivier.nicole@cs.ait.ac.th> wrote: >>>> >>>>> Sam, >>>>> >>>>> > my problem is to know how define a network with mask 8 and dhcp >>>>> server >>>>> > works correctly with it! you know if i config my dhcpd.conf like >>>>> below, i >>>>> > have core dump either: >>>>> > subnet 10.0.0.0 netmask 255.0.0.0 >>>>> > { >>>>> > range 10.0.0.1 10.255.255.254; >>>>> > } >>>>> > >>>>> > do you know how should i define my range ?? >>>>> >>>>> The reason may be that 2^24 machines in a subnet is such a non-sense >>>>> that dhcp simply cannot manage it. >>>>> >>>>> Best regards, >>>>> >>>>> Olivier >>>>> >>>>> > >>>>> > On Tue, Aug 6, 2013 at 12:23 PM, Olivier Nicole < >>>>> Olivier.Nicole@cs.ait.ac.th >>>>> >> wrote: >>>>> > >>>>> >> Sam, >>>>> >> >>>>> >> > subnet 192.0.0.0 netmask 255.0.0.0 >>>>> >> >>>>> >> I know it is not the answer to your question, but you are wrong in >>>>> your >>>>> >> guess that 192.0.0.0/8 is all private IPs. Only 192.168.0.0/16 is. >>>>> >> >>>>> >> I know that for certain because my own IP starts with 192. >>>>> >> >>>>> >> If you want a full /8 private, you can only use 10.0.0.0/8 >>>>> >> >>>>> >> Bets regards, >>>>> >> >>>>> >> Olivier >>>>> >> >>>>> >> -- >>>>> >> >>>>> >>>>> >>>> Well, I would guess it may run out of memory... I did a few tests: >>>> 192.0.0.0 - 192.128.255.255 does work ( using ~2.5Gb RAM ). >>>> 192.0.0.0 - 192.192.255.255 does work ( using ~4Gb RAM ). >>>> 192.0.0.0 - 192.200.255.255 does work ( using ~4.2Gb RAM ). >>>> 192.0.0.0 - 192.224.255.255 dumps core >>>> >>>> Why would you want to have such a huge range? >>>> >>>> Best regards >>>> Andreas >>>> >>> >>> Also, a quick look at the core file gives same indications: >>> #0 0x0000000800c67a21 in _malloc_prefork () from /lib/libc.so.7 >>> #1 0x0000000800c6b72a in malloc () from /lib/libc.so.7 >>> #2 0x000000000047b43b in omapi_object_dereference () >>> #3 0x00000000004844db in do_ip4_hash () >>> #4 0x0000000000484571 in do_ip4_hash () >>> #5 0x0000000000438a45 in pool_timer () >>> #6 0x000000000041dcd7 in trace_conf_stop () >>> #7 0x000000000041fc4e in trace_conf_stop () >>> #8 0x0000000000420698 in trace_conf_stop () >>> #9 0x0000000000420ecc in trace_conf_stop () >>> #10 0x0000000000420197 in trace_conf_stop () >>> #11 0x00000000004247f3 in trace_conf_stop () >>> #12 0x000000000041f210 in trace_conf_stop () >>> #13 0x000000000040f3bf in lease_pinged () >>> #14 0x000000000040d451 in ?? () >>> #15 0x00000008007d7000 in ?? () >>> #16 0x0000000000000000 in ?? () >>> >>> Best regards >>> Andreas >>> >>> >> > From owner-freebsd-net@FreeBSD.ORG Wed Aug 7 07:18:03 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B089A427; Wed, 7 Aug 2013 07:18:03 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 520FC2C56; Wed, 7 Aug 2013 07:18:02 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id u10so1255543lbi.28 for ; Wed, 07 Aug 2013 00:18:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=0KxcqGC3WvWiRDlyeUqaPPUJNeQU620FtJBwCg/XN4c=; b=jOAWpdA8Cq+lwF5MdP33CeExc4xFk6p8i3RX3LRbwdgDZrnEeVhrAcO52oaRyFwnHr nZcOCyxtsjpifhxu8uHP6qOBWdnJyVdSrM8DiZFL0c8aNFuGqixiYeHd7ffakPCoSSI5 8P+WMo3JjgkYNt4ePl5tQkwfYbWvKgnjPGcwjruag4WWmXCt+B+wUrbufMG5jHGY4oOx iiQGkbZhzcsIjV8sq++GAS2cIXfYhKki4Z6OmMqtSfUpoGVwORkXatmMwSYIsD2xHB+j SBR7592Zybgygn3aoGOflCsyuWDDvaeZcMERGM/EGUGyWT8mezSSHob2ByQudeQtwdX1 uMTA== MIME-Version: 1.0 X-Received: by 10.152.19.97 with SMTP id d1mr795779lae.34.1375859880203; Wed, 07 Aug 2013 00:18:00 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.200.165 with HTTP; Wed, 7 Aug 2013 00:17:59 -0700 (PDT) In-Reply-To: <201308070326.r773QCLD035541@mail.karels.net> References: <20130805215319.GA43271@onelab2.iet.unipi.it> <201308070326.r773QCLD035541@mail.karels.net> Date: Wed, 7 Aug 2013 09:18:00 +0200 X-Google-Sender-Auth: a7yRlQjeUh-lwQ89EstnIQoZ08w Message-ID: Subject: Re: [net] protecting interfaces from races between control and data ? From: Luigi Rizzo To: mike@karels.net Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Adrian Chadd , Andre Oppermann , current@freebsd.org, Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 07:18:03 -0000 On Wed, Aug 7, 2013 at 5:26 AM, Mike Karels wrote: > I'm replying to one of the last messages of this thread, but in part going > back to the beginning; then I'm following up on Andre's proposal. > > Luigi wrote: > > i am slightly unclear of what mechanisms we use to prevent races > > between interface being reconfigured (up/down/multicast setting, etc, > > all causing reinitialization of the rx and tx rings) and > > > i) packets from the host stack being sent out; > > ii) interrupts from the network card being processed. > > > I think in the old times IFF_DRV_RUNNING was used for this purpose, > > but now it is not enough. > > Acquiring the "core lock" in the NIC does not seem enough, either, > > because newer drivers, especially multiqueue ones, have per-queue > > rx and tx locks. > > > Does anyone know if there is a generic mechanism, or each driver > > reimplements its own way ? > > I'm not sure I understand the question, or its motivation. What problem(s) > are we trying to solve here? It seems to me that this is mostly internal > to drivers, and I don't see the issue with races. In particular, the only > external guarantees that I see are that control operations will affect the > packet stream "soon" but at some undefined place. Not all of the cited > operations (e.g. multicast changes) need to cause the rings to be > reinitialized; if they do, that's a chip or driver flaw. Clearing the UP > flag should cause packets to stop arriving "soon", but presumably > processing > those already in memory; packets to stop being sent "soon", probably > including > some already accepted for transmission; and new attempts to transmit > receiving > an error "soon". And, of course, the driver should not crash or misbehave. > Other than that, I don't see what external guarantees need to be met. > i only want 'driver should not crash or misbehave', which is something that (I believe) many current drivers do not guarantee because of the races mentioned in the thread (control path reinitializes rings without waiting for the datapath to drain). My specific problem was achieving this safe behaviour when moving between netmap mode and regular mode; i hoped i could replicate whatever scheme was implemented by the drivers in 'normal' mode, and this is when i realized that there was no such protection in place. Jumping to (near) the end of the thread, I like most of Andre's proposal. > Running with minimal locks at this layer is an admirable goal, and I agree > with most of what was said. I have a few observations on the general > changes, > or related issues: > > There was mention of taskqueues. I think that with MSI-X, taskqueues > should not be needed or used. More specifically, having separate ithreads > and taskqueues, with ithreads deferring to taskqueues after some limit, > makes > sense only for MSI and legacy interrupts. With MSI-X, an interrupt thread > should be able to process packets indefinitely with sufficient CPU > resources, > and there is no reason to context switch to a different thread > periodically. > A periodic "yield" might be reasonable, but if it is necessary, small > packet > performance will suffer. However, most of this is internal to the driver. > i am not completely clear on what is the difference between ithreads and taskqueues. Also, Andre's proposal requires to force-kill the ithread, but i am unclear on how to do it safely (i.e. without leaving the data structures in some inconsistent state), unless ithread periodically yields the CPU when it is in a safe state. While this is internal to the driver, we should probably provide some template code to avoid that each driver implements its own way to shutdown the ithread. cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Aug 7 15:16:38 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6B69FC5A for ; Wed, 7 Aug 2013 15:16:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3FEAE2282 for ; Wed, 7 Aug 2013 15:16:38 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8CD9DB962; Wed, 7 Aug 2013 11:16:36 -0400 (EDT) From: John Baldwin To: Meny Yossefi Subject: Re: kern/180430: [ofed] [patch] Bad UDP checksum calc for fragmented packets Date: Wed, 7 Aug 2013 11:15:38 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <201307251634.r6PGYwQN069590@freefall.freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201308071115.38435.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 07 Aug 2013 11:16:36 -0400 (EDT) Cc: "freebsd-net@FreeBSD.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 15:16:38 -0000 On Monday, August 05, 2013 6:49:01 am Meny Yossefi wrote: > John, > > Will this be committed to 9.2 as well ? Yes, I committed it yesterday. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Wed Aug 7 15:32:27 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2D17CF3C for ; Wed, 7 Aug 2013 15:32:27 +0000 (UTC) (envelope-from darrenr@netbsd.org) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F3F7E2377 for ; Wed, 7 Aug 2013 15:32:26 +0000 (UTC) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 8962B20F83; Wed, 7 Aug 2013 11:32:25 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Wed, 07 Aug 2013 11:32:25 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:reply-to :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=a6HguYZ0q1SnRxHpWm2+Z/ q/nvw=; b=gTedB9UhOOngAsY0URQMVi5rxWZC5//gyQoMcXtvc8wjDj8vLRid3w j5Kuin955+MLMi9iIQdxCSpx0Tb3knJ05TKmXGNHZB5KrtSbTM1fELO5qVsLPfhZ Pjq4ni6AqhRzG5wmBj9dbLwfMk2v6YM7YUx4g/Q2G6lPNChjjYyh4= X-Sasl-enc: JfLj8g31akUqzo/mXT/arWeavsS6KBJ2r9uMjp/TIbkZ 1375889544 Received: from [172.20.10.2] (unknown [1.156.19.30]) by mail.messagingengine.com (Postfix) with ESMTPA id A81926800B3; Wed, 7 Aug 2013 11:32:23 -0400 (EDT) Message-ID: <5202693C.50608@netbsd.org> Date: Thu, 08 Aug 2013 01:35:24 +1000 From: Darren Reed Organization: NetBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Mindaugas Rasiukevicius Subject: Re: BPF_MISC+BPF_COP and BPF_COPX References: <20130804191310.2FFBB14A152@mail.netbsd.org> In-Reply-To: <20130804191310.2FFBB14A152@mail.netbsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tech-net@netbsd.org, guy@alum.mit.edu, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: darrenr@netbsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 15:32:27 -0000 On 5/08/2013 5:12 AM, Mindaugas Rasiukevicius wrote: > Hello, > > I would like propose new BPF instructions for the misc category: BPF_COP > and BPF_COPX. It would provide a capability of calling an external > function - think of BPF "coprocessor". No. A BPF program is an entity that can be verified as correct from a security perspective.It is also self contained and requires no external references in order to understand. This change brakes the BPF security model because now the BPF program is calling out to some random function as part of the packet matching. > It provides us a capability to offload more complex packet processing. > My primary user would be NPF in NetBSD, e.g. one of the operations is to > lookup an IP address in a table/ipset. Then add BPF instructions to manipulate address sets (add, remove, lookup) and pick a datastore to use to support it. In doing that the benefits can thereafter be applied to other programs (such as tcpdump) that have a large list of entities that need to be matched against. Darren From owner-freebsd-net@FreeBSD.ORG Wed Aug 7 17:47:03 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 01D0413D for ; Wed, 7 Aug 2013 17:47:03 +0000 (UTC) (envelope-from rmind@netbsd.org) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C72EF2C18 for ; Wed, 7 Aug 2013 17:47:02 +0000 (UTC) Received: from ws (localhost [IPv6:::1]) by mail.netbsd.org (Postfix) with SMTP id 9E1C214A0F7; Wed, 7 Aug 2013 17:47:01 +0000 (UTC) Date: Wed, 7 Aug 2013 18:46:41 +0100 From: Mindaugas Rasiukevicius To: Alexander Nasonov Subject: Re: BPF_MISC+BPF_COP and BPF_COPX In-Reply-To: <20130806065903.GA2835@x1000.localdomain> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <20130805203549.GA2241@x1000.localdomain> <20130805214621.C000D14A1C3@mail.netbsd.org> <20130806065903.GA2835@x1000.localdomain> X-Mailer: mail(1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20130807174701.9E1C214A0F7@mail.netbsd.org> Cc: tech-net@netbsd.org, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 17:47:03 -0000 Alexander Nasonov wrote: > > Yes, I may want to keep the state in the memory store or pass the > > arguments through it, since the accumulator might not be enough. > > You have access to a whole packet, why do you need to pass additional > arguments through the store? I'm worried about introducing tight > coupling between these two very different environments and adding > "sugar" for easy interaction is a big step in this direction. Why is it a problem? Given that the byte-code and the functions would come from the same source, some coupling seems natural to me. It is simplistic anyway: some already parsed offsets or values could be passed through the memory store. > > If you prefer getter > > and setter to perform a boundary check and enforce uint32_t type, I am > > fine with that. Although BPF_MEMWORDS constant and words storing > > 32-bit values stayed since 80s.. it is not going to change. > > > > However, abusing void * is wrong. Once bpf_filter(9) is adjusted to > > take an opaque struct bpf_ctx *, the memory store ought to be moved > > into it. > > Ah, you plan to generalize scratch memory. It's probably fine but don't > generalize too many things because people (me at least) want to be able > to recognize the original bpf and its orignal design. Well, you suggested getter/setter. :) > Please note that I allocate scratch memory on the stack in bpfjit. > If you change scratch memory to be under bpf_ctx, you will need to > reimplement quite a lot in bpfjit code. Is it really a lot? We can waste some cycles and just copy them into the stack (if there are any initial values). -- Mindaugas From owner-freebsd-net@FreeBSD.ORG Wed Aug 7 17:55:49 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8F6CF3EA for ; Wed, 7 Aug 2013 17:55:49 +0000 (UTC) (envelope-from rmind@netbsd.org) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 60C062CBD for ; Wed, 7 Aug 2013 17:55:49 +0000 (UTC) Received: from ws (localhost [IPv6:::1]) by mail.netbsd.org (Postfix) with SMTP id 1528014A21F; Wed, 7 Aug 2013 17:55:47 +0000 (UTC) Date: Wed, 7 Aug 2013 18:55:27 +0100 From: Mindaugas Rasiukevicius To: darrenr@netbsd.org Subject: Re: BPF_MISC+BPF_COP and BPF_COPX In-Reply-To: <5202693C.50608@netbsd.org> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <5202693C.50608@netbsd.org> X-Mailer: mail(1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20130807175548.1528014A21F@mail.netbsd.org> Cc: tech-net@netbsd.org, guy@alum.mit.edu, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 17:55:49 -0000 Darren Reed wrote: > > > > I would like propose new BPF instructions for the misc category: BPF_COP > > and BPF_COPX. It would provide a capability of calling an external > > function - think of BPF "coprocessor". > > No. > You do not have to use it. > A BPF program is an entity that can be verified as correct from a > security perspective.It is also self contained and requires no > external references in order to understand. > > This change brakes the BPF security model because now the BPF program > is calling out to some random function as part of the packet matching. BPF byte-code can still be verified. You cannot call random functions, the functions are predetermined and cannot change during the life-cycle. There is a difference. However, it is as secure as calling any other function in the kernel on packet transmission. You can make a bug in your function, but you can as well make it in tcp_input(). > > It provides us a capability to offload more complex packet processing. > > My primary user would be NPF in NetBSD, e.g. one of the operations is to > > lookup an IP address in a table/ipset. > > Then add BPF instructions to manipulate address sets (add, remove, lookup) > and pick a datastore to use to support it. How adding specialised random instructions is better than having a generic mechanism? You mean BPF_SOME_LOOKUP calling some_lookup() suddenly becomes more secure than BPF_MISC+BPF_COP calling the same some_lookup()? > In doing that the benefits can thereafter be applied to other programs > (such as tcpdump) that have a large list of entities that need to be > matched against. They can grow such support using coprocessor. There is no reason why there could not be a generic (or custom) coprocessor which you could simply modload, if you trust it (or blacklist if you do not). -- Mindaugas From owner-freebsd-net@FreeBSD.ORG Wed Aug 7 20:00:26 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E7055777 for ; Wed, 7 Aug 2013 20:00:25 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 554EA251F for ; Wed, 7 Aug 2013 20:00:24 +0000 (UTC) Received: (qmail 55691 invoked from network); 7 Aug 2013 20:46:00 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 7 Aug 2013 20:46:00 -0000 Message-ID: <5202A74E.4060602@freebsd.org> Date: Wed, 07 Aug 2013 22:00:14 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: [net] protecting interfaces from races between control and data ? References: <20130805215319.GA43271@onelab2.iet.unipi.it> <201308070326.r773QCLD035541@mail.karels.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , current@freebsd.org, mike@karels.net, Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 20:00:26 -0000 On 07.08.2013 09:18, Luigi Rizzo wrote: > On Wed, Aug 7, 2013 at 5:26 AM, Mike Karels > wrote: > Jumping to (near) the end of the thread, I like most of Andre's proposal. > Running with minimal locks at this layer is an admirable goal, and I agree > with most of what was said. I have a few observations on the general changes, > or related issues: > > There was mention of taskqueues. I think that with MSI-X, taskqueues > should not be needed or used. More specifically, having separate ithreads > and taskqueues, with ithreads deferring to taskqueues after some limit, makes > sense only for MSI and legacy interrupts. With MSI-X, an interrupt thread > should be able to process packets indefinitely with sufficient CPU resources, > and there is no reason to context switch to a different thread periodically. > A periodic "yield" might be reasonable, but if it is necessary, small packet > performance will suffer. However, most of this is internal to the driver. > > > i am not completely clear on what is the difference between ithreads and taskqueues. The difference between ithreads and taskqueues is actually very small and mostly in name and how they're set up and kicked off when work is to be done. Both are real kernel threads. Most of the confusion, also in Mikes response, seems to come from the name ithreads for interrupt-threads. However an ithread is not running in interrupt context, only the interrupt handler (called filter) does. Scheduling a taskqueue from an ithread is a bit round-about but commonly done. The bus_setup_intr(9) man page isn't helping to clear up the confusion. The idea is that a (legacy) interrupt is handled in two stages: 1) a small function reading the hardware interrupt status register to determine if this hardware actually raised an interrupt, and acknowledge it (to prevent additional interrupts from firing while this one is handled). If it wasn't this card, it hands off to the handler if this interrupt line is shared; 2) the actual function/thread handling the data that was indicated by the interrupt. Only step 1 runs in interrupt context and thus must be very small and avoid any form of blocking. Step 2 is a normal kernel thread set up as an ithread running at an elevated priority compared to user-space processes/threads. MSI and MSI-X always are exclusive and non-shared interrupts. Thus a handler running in interrupt context isn't necessary for non-legacy interrupt sources. The ithread can be scheduled right away to do its work. > Also, Andre's proposal requires to force-kill the ithread, but i am unclear on how to do it > safely (i.e. without leaving the data structures in some inconsistent state), unless ithread > periodically yields the CPU when it is in a safe state. While this is internal to the driver, > we should probably provide some template code to avoid that each driver implements > its own way to shutdown the ithread. Yes, when done a well-tested, stable and performant template will be provided. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Aug 7 20:13:44 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 26247B48 for ; Wed, 7 Aug 2013 20:13:44 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm14-vm6.bullet.mail.ne1.yahoo.com (nm14-vm6.bullet.mail.ne1.yahoo.com [98.138.91.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A8C6E2645 for ; Wed, 7 Aug 2013 20:13:43 +0000 (UTC) Received: from [98.138.90.57] by nm14.bullet.mail.ne1.yahoo.com with NNFMP; 07 Aug 2013 20:08:31 -0000 Received: from [98.138.84.39] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 07 Aug 2013 20:08:31 -0000 Received: from [127.0.0.1] by smtp107.mail.ne1.yahoo.com with NNFMP; 07 Aug 2013 20:08:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1375906111; bh=IR9oBaPkDlnUFSzZL0CnnqJa0XoQ4zgP8uUQ5F9ZiBg=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=rkLuNmvekaud9/jOv/oD7hdqJW5kDYGpYnx13x1Saz9nvLhVgEdXj6duM9xyOXlHvvAeT+CjAaLyL8HPHdv5I4iJpvGSN+BNOt7+etr9xKL9A9GY99eiQEd+xCQRtPeW3yHoQ8bNFy51GPzHbq6zLCbC3iwfUUlXeqceiyrFU0Y= X-Yahoo-Newman-Id: 236115.32192.bm@smtp107.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: fgmBe8AVM1mafGhh1bx84CL3Aa9JBL.MZZz_uPWDjFXWH6o IfBCuts0hZxyW1oGA.q3ZOw45AceUTITvPasRuNWo3jj0wlJRAFjLYy9INL4 m48TAIovVQMzyshAwgxSzjYHwyC3zrmkoqpix5pOHku0KoPntKBLZjrLolm2 hvlRDIe6c99hZ9CcFeZbIhrgDzmuYGcCLlsheJFmeScjIj2bf1waOM9umfbl bmSpszN.9lUXcNS51ou6OEJxdpbZCvfCvvWE63KsSGj1AHB7cKHllYJKpCnP D0qCpyDgV41BNga2LL5MzhLY3QoRy8EBvporNEnen.w4lVr5wNu..j1EAz_A V.nWqyV34dCsyPC_.iLnQQ8tRKaPt1F_o682Knv6qS4Zdy8lYmmPhRh.rr0g lqR6EwdtDDGbrhB_L3Zo8hCmg1_GO9wqJLs9i4.W6j0CJXxQS8g0hWaDDvjj usAzPsnjlrz6mXwgm.zXnOKbBVEF.O4dA1zWXycp6SyzzE1wax6HZg2HtPbm Gp82bNdYNlt_v2Bu0VgijNXxNRuuOQ.Lk8xZvWuC8V3a1lkYiZUz4iOfhKyZ 1uQ-- X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- X-Rocket-Received: from phobos.corp.netflix.com (scott4long@69.53.237.66 with ) by smtp107.mail.ne1.yahoo.com with SMTP; 07 Aug 2013 13:08:31 -0700 PDT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [net] protecting interfaces from races between control and data ? From: Scott Long In-Reply-To: <5202A74E.4060602@freebsd.org> Date: Wed, 7 Aug 2013 14:08:29 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130805215319.GA43271@onelab2.iet.unipi.it> <201308070326.r773QCLD035541@mail.karels.net> <5202A74E.4060602@freebsd.org> To: Andre Oppermann X-Mailer: Apple Mail (2.1508) Cc: Adrian Chadd , mike@karels.net, Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri , Luigi Rizzo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 20:13:44 -0000 On Aug 7, 2013, at 2:00 PM, Andre Oppermann wrote: > On 07.08.2013 09:18, Luigi Rizzo wrote: >> On Wed, Aug 7, 2013 at 5:26 AM, Mike Karels > wrote: >> Jumping to (near) the end of the thread, I like most of Andre's = proposal. >> Running with minimal locks at this layer is an admirable goal, and = I agree >> with most of what was said. I have a few observations on the = general changes, >> or related issues: >>=20 >> There was mention of taskqueues. I think that with MSI-X, = taskqueues >> should not be needed or used. More specifically, having separate = ithreads >> and taskqueues, with ithreads deferring to taskqueues after some = limit, makes >> sense only for MSI and legacy interrupts. With MSI-X, an = interrupt thread >> should be able to process packets indefinitely with sufficient CPU = resources, >> and there is no reason to context switch to a different thread = periodically. >> A periodic "yield" might be reasonable, but if it is necessary, = small packet >> performance will suffer. However, most of this is internal to the = driver. >>=20 >>=20 >> i am not completely clear on what is the difference between ithreads = and taskqueues. >=20 > The difference between ithreads and taskqueues is actually very small = and mostly in > name and how they're set up and kicked off when work is to be done. = Both are real > kernel threads. Most of the confusion, also in Mikes response, seems = to come from > the name ithreads for interrupt-threads. However an ithread is not = running in > interrupt context, only the interrupt handler (called filter) does. = Scheduling a > taskqueue from an ithread is a bit round-about but commonly done. The = bus_setup_intr(9) > man page isn't helping to clear up the confusion. >=20 I think it might still be the case that threads are not allowed to = sleep. That means no sx locks and no malloc(M_WAITOK), along with the obvious = tsleep/msleep. Taskqueues have no such restriction. An even rore relevant difference is that taskqueues have a much stronger management API. Ithreads can only be scheduled by generating a hardware = interrupt, can only be drained by calling bus_teardown_intr(), and cannot be = paused. Taskqueues give you direct access to this control. Scott From owner-freebsd-net@FreeBSD.ORG Wed Aug 7 20:18:26 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 835CFC41 for ; Wed, 7 Aug 2013 20:18:26 +0000 (UTC) (envelope-from alnsn@yandex.ru) Received: from mail.o2.co.uk (jabba.london.02.net [82.132.130.169]) by mx1.freebsd.org (Postfix) with ESMTP id 48E24267A for ; Wed, 7 Aug 2013 20:18:25 +0000 (UTC) Received: from localhost (78.86.33.51) by mail.o2.co.uk (8.5.140.03) (authenticated as nasonov) id 51DA940306009A93; Wed, 7 Aug 2013 21:17:12 +0100 Date: Wed, 7 Aug 2013 21:17:12 +0100 From: Alexander Nasonov To: Mindaugas Rasiukevicius Subject: Re: BPF_MISC+BPF_COP and BPF_COPX Message-ID: <20130807201712.GA2042@x1000.localdomain> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <20130805203549.GA2241@x1000.localdomain> <20130805214621.C000D14A1C3@mail.netbsd.org> <20130806065903.GA2835@x1000.localdomain> <20130807174701.9E1C214A0F7@mail.netbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130807174701.9E1C214A0F7@mail.netbsd.org> X-Operating-System: Linux 3.4.0 on armv7l X-SHELL: /bin/bash X-FCEDIT: /bin/ed X-EDITOR: /usr/bin/vi X-VISUAL: vim User-Agent: Mutt/1.5.21 (2010-09-15) Cc: tech-net@netbsd.org, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 20:18:26 -0000 Mindaugas Rasiukevicius wrote: > Why is it a problem? Given that the byte-code and the functions would come > from the same source, some coupling seems natural to me. It is simplistic > anyway: some already parsed offsets or values could be passed through the > memory store. You surely have some picture in mind but I can't get it. I'm a bit worried that two different environments may look unnatural when married together. Perhaps, you should right a proposal with some use-cases to support your points. > > > > Ah, you plan to generalize scratch memory. It's probably fine but don't > > generalize too many things because people (me at least) want to be able > > to recognize the original bpf and its orignal design. > > Well, you suggested getter/setter. :) Yeah, please write a proposal ;-) > > Please note that I allocate scratch memory on the stack in bpfjit. > > If you change scratch memory to be under bpf_ctx, you will need to > > reimplement quite a lot in bpfjit code. > > Is it really a lot? We can waste some cycles and just copy them into the > stack (if there are any initial values). Not really a lot given a size of bpfjit.c but if you hit some limitation of sljit, be prepared to do extra coding to work around it. Alex From owner-freebsd-net@FreeBSD.ORG Wed Aug 7 20:48:35 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D049AA17; Wed, 7 Aug 2013 20:48:35 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 15E3E287A; Wed, 7 Aug 2013 20:48:34 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id j13so8822wgh.1 for ; Wed, 07 Aug 2013 13:48:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=PT5MUtyS8orVKPzlULFz8/3CO5Me/u1ydKaZgPTklCY=; b=HJWK7CkhBUKNuk9x18viY77YS7agDZUV4hPx+kRllqw3/FWuq12Sr0a0wf5GUWaA/O m9dAb3S79WvaqxsdsagqYIqbIq9qKkHplqXf0j2p5HrazcoDksn+YLGOI/Po8+I5jshj qjUeEPGjtFUip4eDH3z8oweAQUFEIy8rd3zHDQgQscg81XeEicEUTALx36hfPmsCUJ0R BNXMUlD+0IIZkd8tMfz/MjVXy1UdebBtSqAxXvX89Qi9MjYuE+/2L860LBXnl4Ja/6tv Ge27RE+413QzJZkhYnImzi+ZYHLoIHW7I1Typ0VxkeHct7RrPT4YQGki9nJczbv0NlTc cmXA== MIME-Version: 1.0 X-Received: by 10.180.160.165 with SMTP id xl5mr3242130wib.46.1375908513364; Wed, 07 Aug 2013 13:48:33 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Wed, 7 Aug 2013 13:48:33 -0700 (PDT) In-Reply-To: References: <20130805215319.GA43271@onelab2.iet.unipi.it> <201308070326.r773QCLD035541@mail.karels.net> <5202A74E.4060602@freebsd.org> Date: Wed, 7 Aug 2013 13:48:33 -0700 X-Google-Sender-Auth: 9S3rtyi_XfEeWs8jEZE9kbTR8F8 Message-ID: Subject: Re: [net] protecting interfaces from races between control and data ? From: Adrian Chadd To: Scott Long Content-Type: text/plain; charset=ISO-8859-1 Cc: Andre Oppermann , mike@karels.net, Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri , Luigi Rizzo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 20:48:35 -0000 On 7 August 2013 13:08, Scott Long wrote: > An even rore relevant difference is that taskqueues have a much stronger > management API. Ithreads can only be scheduled by generating a hardware interrupt, > can only be drained by calling bus_teardown_intr(), and cannot be paused. Taskqueues > give you direct access to this control. It would be really nice if we had a software method to trigger an ithread to run, like a software interrupt. It would also be nice to pin taskqueues to CPUs, we can do with ithreads at the moment. -adrian From owner-freebsd-net@FreeBSD.ORG Wed Aug 7 21:29:41 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B26BA6BF for ; Wed, 7 Aug 2013 21:29:41 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 201352B09 for ; Wed, 7 Aug 2013 21:29:40 +0000 (UTC) Received: (qmail 56016 invoked from network); 7 Aug 2013 22:15:15 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 7 Aug 2013 22:15:15 -0000 Message-ID: <5202BC3A.7010505@freebsd.org> Date: Wed, 07 Aug 2013 23:29:30 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [net] protecting interfaces from races between control and data ? References: <20130805215319.GA43271@onelab2.iet.unipi.it> <201308070326.r773QCLD035541@mail.karels.net> <5202A74E.4060602@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Scott Long , mike@karels.net, Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri , Luigi Rizzo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 21:29:41 -0000 On 07.08.2013 22:48, Adrian Chadd wrote: > On 7 August 2013 13:08, Scott Long wrote: > >> An even rore relevant difference is that taskqueues have a much stronger >> management API. Ithreads can only be scheduled by generating a hardware interrupt, >> can only be drained by calling bus_teardown_intr(), and cannot be paused. Taskqueues >> give you direct access to this control. > > It would be really nice if we had a software method to trigger an > ithread to run, like a software interrupt. > > It would also be nice to pin taskqueues to CPUs, we can do with > ithreads at the moment. Both are implemented on top of kernel threads so it's mostly a matter of nicely integrating and exposing an API for it. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Aug 8 03:40:23 2013 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EA3DC837; Thu, 8 Aug 2013 03:40:23 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BF836204E; Thu, 8 Aug 2013 03:40:23 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r783eEgM080406; Thu, 8 Aug 2013 03:40:14 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id jib69syhahekvvuirrqjuubqke; Thu, 08 Aug 2013 03:40:14 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: [net] protecting interfaces from races between control and data ? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <520127C3.3020101@freebsd.org> Date: Wed, 7 Aug 2013 20:40:14 -0700 Content-Transfer-Encoding: 7bit Message-Id: <696F42E9-B1E6-4198-BD55-F7595932E320@kientzle.com> References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> <5200136C.8000201@freebsd.org> <20130805215319.GA43271@onelab2.iet.unipi.it> <520127C3.3020101@freebsd.org> To: Andre Oppermann X-Mailer: Apple Mail (2.1283) Cc: Adrian Chadd , current@FreeBSD.org, Bryan Venteicher , Navdeep Parhar , net@FreeBSD.org, Giuseppe Lettieri , Luigi Rizzo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 03:40:24 -0000 On Aug 6, 2013, at 9:43 AM, Andre Oppermann wrote: > The driver supplies a TX frame transmit function (mostly like if_transmit > today) which does all locking and multi-queue handling internally (driver > owned. This gives driver writers the freedom to better adjust to different > hardware communication methods as they become available, like we witnessed > a couple of times in the past. How would you handle TX dequeue? I'm curious because I got a nice speedup with cpsw by not using the TX interrupt at all: I just dequeued completed packets at the end of the TX transmit function. I suppose this would still work with your scheme. Tim From owner-freebsd-net@FreeBSD.ORG Thu Aug 8 03:40:24 2013 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0732E83B; Thu, 8 Aug 2013 03:40:24 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D13D3204F; Thu, 8 Aug 2013 03:40:20 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r783e84H080403; Thu, 8 Aug 2013 03:40:08 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id u9zpp422c7ztvadbitukha32a2; Thu, 08 Aug 2013 03:40:08 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: [net] protecting interfaces from races between control and data ? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <520127C3.3020101@freebsd.org> Date: Wed, 7 Aug 2013 20:37:36 -0700 Content-Transfer-Encoding: 7bit Message-Id: <170757A0-2A8A-4F48-B5A0-20EC725B963B@kientzle.com> References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> <5200136C.8000201@freebsd.org> <20130805215319.GA43271@onelab2.iet.unipi.it> <520127C3.3020101@freebsd.org> To: Andre Oppermann X-Mailer: Apple Mail (2.1283) Cc: Adrian Chadd , current@FreeBSD.org, Bryan Venteicher , Navdeep Parhar , net@FreeBSD.org, Giuseppe Lettieri , Luigi Rizzo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 03:40:24 -0000 On Aug 6, 2013, at 9:43 AM, Andre Oppermann wrote: > The driver supplies a TX frame transmit function (mostly like if_transmit > today) which does all locking and multi-queue handling internally (driver > owned. This gives driver writers the freedom to better adjust to different > hardware communication methods as they become available, like we witnessed > a couple of times in the past. How would you handle TX dequeue? I'm curious because I got a nice speedup with cpsw by not using the TX interrupt at all: I just dequeued completed packets at the end of the TX transmit function. I suppose this would still work with your scheme. Tim From owner-freebsd-net@FreeBSD.ORG Thu Aug 8 07:01:26 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4140466B for ; Thu, 8 Aug 2013 07:01:26 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0B1362A5B for ; Thu, 8 Aug 2013 07:01:25 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id w15so1229131iea.5 for ; Thu, 08 Aug 2013 00:01:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=A6d5m82Sa/9n59wqACzPWp2Y7d3RMd9JFkFh0a1SBHM=; b=i+9WNxjRK1Bku1kN20AjnoloCzqdhv2yJjxIHQRhMAK40YwHkGBt2dHrF5CIPJt1eB 9iZbxOaB331pDu40jZdqocG2DnmOFYd+fAE93Yh5CPZckIraHKP5OZ9g4EXB4/kYMmyt lhhrmuBaoI6B/3RdtXw48HJN8AYhBu/6tBjlhBwkZ5ccg5rMZTaK15uNxWhsrFs6kj4b waQA2N7pE0B8gi8nMQv3jsRRzWI9DWE3cRLjW8oLiucA9VlgH191qn6SMrKZgJ7Mc8YX D+KGD8OAD3N45cey6rOSTS7Pi4XAvqQSguw2l0KUfX7ijTu/YZ8uumU7E5Lzw4NfFX70 Uu1w== X-Gm-Message-State: ALoCoQnQoDgdH3l2ELsn7d9+Ss2wgMd+EVJ4DALh7lEIt7SRiCOjpaLh2RUmE4d7chE9Z3MIulcU X-Received: by 10.42.83.201 with SMTP id i9mr1296037icl.110.1375938998922; Wed, 07 Aug 2013 22:16:38 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id io8sm5063623igb.7.2013.08.07.22.16.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 Aug 2013 22:16:38 -0700 (PDT) Sender: Warner Losh Subject: Re: [net] protecting interfaces from races between control and data ? Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Wed, 7 Aug 2013 23:16:36 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1085) Cc: current@freebsd.org, Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri , Luigi Rizzo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 07:01:26 -0000 On Aug 5, 2013, at 11:20 AM, Adrian Chadd wrote: > .. and I bet it's not a design pattern, and this is total conjecture = on my part: >=20 > * the original drivers weren't SMP safe; > * noone really sat down and figured out how to correctly synchronise > all of this stuff; > * people did the minimum amount of work to keep the driver from > immediately crashing, but didn't really think things through at a > larger scale. >=20 > Almost every driver is this way Luigi. :-) Most of the drivers in the three don't support hardware that performs = well enough for this to be a problem. :) Any driver that's still around = from the pre-locking days can easily saturate the lines (or the = hardware) on today's (and even yesterday's hardware). All the rest have come up with different ways to cope... Warner From owner-freebsd-net@FreeBSD.ORG Thu Aug 8 07:04:25 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9214071C for ; Thu, 8 Aug 2013 07:04:25 +0000 (UTC) (envelope-from sam.gh1986@gmail.com) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1B38C2A76 for ; Thu, 8 Aug 2013 07:04:24 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id fq13so1856134lab.39 for ; Thu, 08 Aug 2013 00:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=4Mh3UDu3awA/nQ/du4HVDosnoPS0jT31yhAtsAI07AU=; b=pOWk9PccUiJA9B1K4E0CGSW5dk0ymTBxKSy56yyw3Ce4cUiL9Tc5dvPn7V4rU5xnhL KPtrXq82jNeRphmVF5s3inkROLLXsa0MRVDwOzG7KDY+/FzWTS/2ip1J/f/K2D3ifcvn A5vGcgE2orGaVE7Aqtw4Pop/9vNyPqHtF2eqo1/diCj25UnwGi64yWMlSW1YKf4H0mG5 0zMdtb6d4Uo5c0yZ/2zzsKi9WJFwMOlDnwtdNkiTHELCClF7SLjDDaIeXDm+U0hxa9FZ DE8umxSC53qkyC9WBuvT880iqONml+AbWCX5Sb2Wa1wwjeAXibMejhdaI7ueqGhuI8fT PMPA== MIME-Version: 1.0 X-Received: by 10.152.121.73 with SMTP id li9mr3059109lab.42.1375945462968; Thu, 08 Aug 2013 00:04:22 -0700 (PDT) Received: by 10.112.147.230 with HTTP; Thu, 8 Aug 2013 00:04:22 -0700 (PDT) Date: Thu, 8 Aug 2013 11:34:22 +0430 Message-ID: Subject: how calculate the number of ip addresses in a range? From: s m To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 07:04:25 -0000 hello guys, i have a question about ip addresses. i know my question is not related to freebsd but i googled a lot and found nothing useful and don't know where i should ask my question. i want to know how can i calculate the number of ip addresses in a range? for example if i have 192.0.0.1 192.100.255.254 with mask 8, how many ip addresses are available in this range? is there any formula to calculate the number of ip addresses for any range? i'm confusing about it. please help me to clear my mind. thanks in advance, SAM From owner-freebsd-net@FreeBSD.ORG Thu Aug 8 08:11:20 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A49D81C7 for ; Thu, 8 Aug 2013 08:11:20 +0000 (UTC) (envelope-from darrenr@netbsd.org) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 778E32D7C for ; Thu, 8 Aug 2013 08:11:20 +0000 (UTC) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 7040D2112A; Thu, 8 Aug 2013 04:11:18 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Thu, 08 Aug 2013 04:11:18 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:reply-to :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=36lLe/ZDpKY8rVnizEEzVA 8j1Gk=; b=dATFPscFGAUTgljfkltEeTAqUuYyq3mRXe6xHq2v/DNuBjgvDcVWn/ SNdBD8hoW65vXqVSTN6Lc2m9eZsqLSGvCnmG6wKX5arTF+6H8dt4jt9gcGL83xUN yryH2OaH4MnPstermM/TRWSh/7LYnXqUR9901TKTlNe1YNsynhwHQ= X-Sasl-enc: Rqzd9Vye2fmaWVrLMbwD4b4HbWwjCsAIY3zKiHesqI/B 1375949477 Received: from [172.20.10.2] (unknown [110.144.14.48]) by mail.messagingengine.com (Postfix) with ESMTPA id 55DD8680106; Thu, 8 Aug 2013 04:11:16 -0400 (EDT) Message-ID: <5203535D.2040508@netbsd.org> Date: Thu, 08 Aug 2013 18:14:21 +1000 From: Darren Reed Organization: NetBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Mindaugas Rasiukevicius Subject: Re: BPF_MISC+BPF_COP and BPF_COPX References: <20130804191310.2FFBB14A152@mail.netbsd.org> <5202693C.50608@netbsd.org> <20130807175548.1528014A21F@mail.netbsd.org> In-Reply-To: <20130807175548.1528014A21F@mail.netbsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tech-net@netbsd.org, guy@alum.mit.edu, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: darrenr@netbsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 08:11:20 -0000 On 8/08/2013 3:55 AM, Mindaugas Rasiukevicius wrote: > Darren Reed wrote: >>> >>> I would like propose new BPF instructions for the misc category: BPF_COP >>> and BPF_COPX. It would provide a capability of calling an external >>> function - think of BPF "coprocessor". >> >> No. >> > > You do not have to use it. I get no choice - it is in the kernel by default. >> A BPF program is an entity that can be verified as correct from a >> security perspective.It is also self contained and requires no >> external references in order to understand. >> >> This change brakes the BPF security model because now the BPF program >> is calling out to some random function as part of the packet matching. > > BPF byte-code can still be verified. You cannot call random functions, > the functions are predetermined and cannot change during the life-cycle. > > There is a difference. However, it is as secure as calling any other > function in the kernel on packet transmission. You can make a bug in > your function, but you can as well make it in tcp_input(). No. It's not about calling a function, it is about proving the BPF program is correct and secure. BPF today is essentially assembly language operations that are all easily tested and verified. >>> It provides us a capability to offload more complex packet processing. >>> My primary user would be NPF in NetBSD, e.g. one of the operations is to >>> lookup an IP address in a table/ipset. >> >> Then add BPF instructions to manipulate address sets (add, remove, lookup) >> and pick a datastore to use to support it. > > How adding specialised random instructions is better than having a generic > mechanism? You mean BPF_SOME_LOOKUP calling some_lookup() suddenly becomes > more secure than BPF_MISC+BPF_COP calling the same some_lookup()? See below. On 8/08/2013 5:18 AM, Joerg Sonnenberger wrote: > On Thu, Aug 08, 2013 at 01:35:24AM +1000, Darren Reed wrote: >> A BPF program is an entity that can be verified as correct from a >> security perspective.It is also self contained and requires no >> external references in order to understand. > > How is this relevant for the discussion? It is important to understand what BPF is before making changes to it. >>> It provides us a capability to offload more complex packet processing. >>> My primary user would be NPF in NetBSD, e.g. one of the operations is to >>> lookup an IP address in a table/ipset. >> >> Then add BPF instructions to manipulate address sets (add, remove, lookup) >> and pick a datastore to use to support it. > > How is that more useful than the proposal? Actually, add/remove are not instructions for the BPF language, only lookup. Add, remove, etc, would be handled in the usual manner. How is that more useful? The capability of the opcodes is programmed into the BPF program, not through some external reference. A BPF program generated on Linux is just as valid as on Solaris or NetBSD. Whilst that may be meaningless because nobody copies BPF programs around (in byte code format), this would open a door on developing specialised behaviour for "my platform" that isn't present elsewhere. This then diminishes the value of BPF. > The BPF design has some serious limitations for modern network > protocols. For example, the forward-jump-only property makes it > impossible to write rules for protocols with arbitrary header > composition. While it is not desirable to completely remove this > restriction, the proposal could help to deal with many of the > interesting case efficently. Correct. The forward jumping only aspect is an important attribute of BPF as it bounds the amount of time that the system can spend on processing the packet. Given that BPF opcodes are evaluated in the hot patch of packet processing, that kind of guarantee is very important. I think your reference here to arbitrary header ordering is in reference to IPv6 - which actually does have some rules about in which order headers can be found. Just as IPv4 has a special instruction with which to find the start of a transport header, I see no reason why something similar shouldn't exist for IPv6. The challenge becomes to think of processing the packet differently and how the relationship between BPF and the packet dictates what instructions are necessary. Darren From owner-freebsd-net@FreeBSD.ORG Thu Aug 8 08:27:12 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 229194D2 for ; Thu, 8 Aug 2013 08:27:12 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D5A5B2E5E for ; Thu, 8 Aug 2013 08:27:11 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id hu16so154187qab.3 for ; Thu, 08 Aug 2013 01:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IhR3esDGbOpo0etRqvsQptgRJ7B2aIhZ1RFqH31IQcs=; b=tGYL5yyEhRFYDh+hPSkqkpG+VQhYriOUImpbhtGRHjcJtLV6rQr8DJJwh5HQHiPV0S VUifwEaXoMWMSeJIYdJwPpzoHp9l/bqbvkwxYMZFqaMsDMLszxKBwNQ6QPvbWXYhUaKY ddk6ZEGLY5wHXBPy+SLszU3D8wf3lYilu/lSQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IhR3esDGbOpo0etRqvsQptgRJ7B2aIhZ1RFqH31IQcs=; b=OdZZhRBaz4z+1niImEmEItvLzEk1e9FW+9iHbYLlT0+7AGvgkUfQQtD6/Sg3jEiTXK tWFEv+wNsUDSfwOdSqtF3Fd77MxxemaE4az8YCMqF41ad2dZY17Ypw/edezv+VCoMHgJ W/oIIPSW/uMwCO2YAP4R+/VGXTDEOL8A48Ht7CBdfYlu1pTW632/E/G5cVBuyqqqoz16 0RlN3hoask1dvI1CGkn01pFnQ706r8yWvzEGdtDJaY5mLAuKRAEc+KwxFu/MxPRswep0 t/ZvX0M4/lUAPydgb1yz5uVRBpelqwI4BcT4qeRJEhnZSXoLII1RJfZXeA62uPOUWlum pxqg== X-Gm-Message-State: ALoCoQmyOdwxW72Sx2H/Ovw2TcTrbxpz+Sypam/5kzoFHw2a7ydrya2wVfDHo/OInAE8uOC5DKqh MIME-Version: 1.0 X-Received: by 10.224.137.73 with SMTP id v9mr2984791qat.16.1375950430956; Thu, 08 Aug 2013 01:27:10 -0700 (PDT) Received: by 10.49.36.5 with HTTP; Thu, 8 Aug 2013 01:27:10 -0700 (PDT) In-Reply-To: References: Date: Thu, 8 Aug 2013 01:27:10 -0700 Message-ID: Subject: Re: how calculate the number of ip addresses in a range? From: Peter Wemm To: s m Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 08:27:12 -0000 On Thu, Aug 8, 2013 at 12:04 AM, s m wrote: > hello guys, > > i have a question about ip addresses. i know my question is not related to > freebsd but i googled a lot and found nothing useful and don't know where i > should ask my question. > > i want to know how can i calculate the number of ip addresses in a range? > for example if i have 192.0.0.1 192.100.255.254 with mask 8, how many ip > addresses are available in this range? is there any formula to calculate > the number of ip addresses for any range? > > i'm confusing about it. please help me to clear my mind. > thanks in advance, My immediate reaction is.. is this a homework / classwork / assignment? Anyway, you can think of it by converting your start and end addresses to an integer. Over simplified: $ cat homework.c main() { int start = (192 << 24) | (0 << 16) | (0 << 8) | 1; int end = (192 << 24) | (100 << 16) | (255 << 8) | 254; printf("start %d end %d range %d\n", start, end, (end - start) + 1); } $ ./homework start -1073741823 end -1067122690 range 6619134 The +1 is correcting for base zero. 192.0.0.1 - 192.0.0.2 is two usable addresses. I'm not sure what you want to do with the mask of 8. You can also do it with ntohl(inet_addr("address")) as well and a multitude of other ways. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV UTF-8: for when a ' just won\342\200\231t do. ZFS must be the bacon of file systems. "everything's better with ZFS" From owner-freebsd-net@FreeBSD.ORG Thu Aug 8 09:16:58 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B919C721 for ; Thu, 8 Aug 2013 09:16:58 +0000 (UTC) (envelope-from guy@alum.mit.edu) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9FDA721E1 for ; Thu, 8 Aug 2013 09:16:58 +0000 (UTC) Received: from [10.0.1.2] ([66.201.46.179]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id r788RS9x015404 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 Aug 2013 01:27:28 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: BPF_MISC+BPF_COP and BPF_COPX From: Guy Harris In-Reply-To: <5203535D.2040508@netbsd.org> Date: Thu, 8 Aug 2013 01:27:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0C9DFD21-D09F-4163-BF90-4258838577A7@alum.mit.edu> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <5202693C.50608@netbsd.org> <20130807175548.1528014A21F@mail.netbsd.org> <5203535D.2040508@netbsd.org> To: darrenr@netbsd.org X-Mailer: Apple Mail (2.1503) Cc: tech-net@netbsd.org, Mindaugas Rasiukevicius , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 09:16:58 -0000 On Aug 8, 2013, at 1:14 AM, Darren Reed wrote: > A BPF program generated on Linux is just as valid as on Solaris or = NetBSD. Not necessarily - negative offsets in load and store instructions are = supported on Linux to access some metadata that's not in the packet = data, but those aren't, as far as I know, supported on other platforms. However, there is a subset of BPF that all kernel BPF implementations, = and the userland implementation in libpcap, support.= From owner-freebsd-net@FreeBSD.ORG Thu Aug 8 10:33:06 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 225CFB5F for ; Thu, 8 Aug 2013 10:33:06 +0000 (UTC) (envelope-from rmind@netbsd.org) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E859F26B1 for ; Thu, 8 Aug 2013 10:33:05 +0000 (UTC) Received: from ws (localhost [IPv6:::1]) by mail.netbsd.org (Postfix) with SMTP id 2542614A2A9; Thu, 8 Aug 2013 10:33:03 +0000 (UTC) Date: Thu, 8 Aug 2013 11:32:45 +0100 From: Mindaugas Rasiukevicius To: Alexander Nasonov Subject: Re: BPF_MISC+BPF_COP and BPF_COPX In-Reply-To: <20130807201712.GA2042@x1000.localdomain> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <20130805203549.GA2241@x1000.localdomain> <20130805214621.C000D14A1C3@mail.netbsd.org> <20130806065903.GA2835@x1000.localdomain> <20130807174701.9E1C214A0F7@mail.netbsd.org> <20130807201712.GA2042@x1000.localdomain> X-Mailer: mail(1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20130808103304.2542614A2A9@mail.netbsd.org> Cc: tech-net@netbsd.org, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 10:33:06 -0000 Alexander Nasonov wrote: > Mindaugas Rasiukevicius wrote: > > Why is it a problem? Given that the byte-code and the functions would > > come from the same source, some coupling seems natural to me. It is > > simplistic anyway: some already parsed offsets or values could be > > passed through the memory store. > > You surely have some picture in mind but I can't get it. I'm a bit > worried that two different environments may look unnatural when married > together. OK, but you did not explain why is it a problem i.e. why is it worrying? > Perhaps, you should right a proposal with some use-cases to support your > points. They are simple: consider detecting IP version and calculating the offset to L4 header. There is no reason to duplicate this work in the byte-code and the coprocessor. If one of them does it - let's just save it. > > > Ah, you plan to generalize scratch memory. It's probably fine but > > > don't generalize too many things because people (me at least) want to > > > be able to recognize the original bpf and its orignal design. > > > > Well, you suggested getter/setter. :) > > Yeah, please write a proposal ;-) > int bpf_get_memword(const bpf_ctx_t *c, size_t i, uint32_t *val); int bpf_set_memword(bpf_ctx_t *c, size_t i, uint32_t val); You prefer something like this? -- Mindaugas From owner-freebsd-net@FreeBSD.ORG Thu Aug 8 11:15:02 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 80F894DC for ; Thu, 8 Aug 2013 11:15:02 +0000 (UTC) (envelope-from rmind@netbsd.org) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6CF162905 for ; Thu, 8 Aug 2013 11:15:02 +0000 (UTC) Received: from ws (localhost [IPv6:::1]) by mail.netbsd.org (Postfix) with SMTP id 1974C14A2B0; Thu, 8 Aug 2013 11:15:00 +0000 (UTC) Date: Thu, 8 Aug 2013 12:14:42 +0100 From: Mindaugas Rasiukevicius To: darrenr@netbsd.org Subject: Re: BPF_MISC+BPF_COP and BPF_COPX In-Reply-To: <5203535D.2040508@netbsd.org> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <5202693C.50608@netbsd.org> <20130807175548.1528014A21F@mail.netbsd.org> <5203535D.2040508@netbsd.org> X-Mailer: mail(1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20130808111501.1974C14A2B0@mail.netbsd.org> Cc: tech-net@netbsd.org, guy@alum.mit.edu, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 11:15:02 -0000 Darren Reed wrote: > > > > You do not have to use it. > > I get no choice - it is in the kernel by default. > There is no default coprocessor. Here is your choice: do not call bpf_set_cop(9) and those instructions will effectively be NOPs. > <...> > > No. It's not about calling a function, it is about proving the BPF > program is correct and secure. > > BPF today is essentially assembly language operations that are all > easily tested and verified. > > <...> > > On 8/08/2013 5:18 AM, Joerg Sonnenberger wrote: > > On Thu, Aug 08, 2013 at 01:35:24AM +1000, Darren Reed wrote: > >> A BPF program is an entity that can be verified as correct from a > >> security perspective.It is also self contained and requires no > >> external references in order to understand. > > > > How is this relevant for the discussion? > > It is important to understand what BPF is before making changes to it. > It is *your* understanding with a premise you just came up. I do not think that your premise is universally accepted. The reason why we have bpf_validate(9) is to ensure that the byte-code cannot cause any harm to the kernel (whether it is an infinite loop, a crash or any other security vulnerability), because it is passed from the *user*. The fundamental difference is that the coprocessor comes from the *kernel*. We tend to trust that the kernel is not self-harming and compilers do constructive job. We cannot validate that (unless you want to challenge Turing's halting problem), but the point being is that we do not need to. > >> Then add BPF instructions to manipulate address sets (add, remove, > >> lookup) and pick a datastore to use to support it. > > > > How is that more useful than the proposal? > > Actually, add/remove are not instructions for the BPF language, > only lookup. Add, remove, etc, would be handled in the usual manner. > > How is that more useful? You contradict yourself here. It still calls some "external reference" which you are arguing against. > The capability of the opcodes is programmed into the BPF program, > not through some external reference. A BPF program generated on > Linux is just as valid as on Solaris or NetBSD. Whilst that may > be meaningless because nobody copies BPF programs around (in byte > code format), this would open a door on developing specialised > behaviour for "my platform" that isn't present elsewhere. This > then diminishes the value of BPF. When I was thinking of BPF_COP/BPF_COPX, I was thinking of MIPS. The capability of the opcodes does not have to be programmed into the BPF program. You still have a core set of BPF instructions which will work everywhere and there is a reason why we have BPF_MISC. I can understand the concern about platforms implementing different behaviour, but your proposal of adding an instruction for every specific operation is not going to help. It is a question of agreement (hence CC freebsd-net). -- Mindaugas From owner-freebsd-net@FreeBSD.ORG Thu Aug 8 11:31:04 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C803FB90 for ; Thu, 8 Aug 2013 11:31:04 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [94.23.254.147]) by mx1.freebsd.org (Postfix) with ESMTP id 90F152A10 for ; Thu, 8 Aug 2013 11:31:04 +0000 (UTC) Received: from roxette.lamaiziere.net (149.169.100.84.rev.sfr.net [84.100.169.149]) by smtp.lamaiziere.net (Postfix) with ESMTPA id 6B08FA130; Thu, 8 Aug 2013 13:30:57 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by roxette.lamaiziere.net (Postfix) with ESMTP id 38294B0DC; Thu, 8 Aug 2013 13:30:56 +0200 (CEST) Date: Thu, 8 Aug 2013 13:30:55 +0200 From: Patrick Lamaiziere To: s m Subject: Re: how calculate the number of ip addresses in a range? Message-ID: <20130808133055.15e53b94@davenulle.org> In-Reply-To: References: X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 11:31:04 -0000 Le Thu, 8 Aug 2013 11:34:22 +0430, s m a écrit : > hello guys, > > i have a question about ip addresses. i know my question is not > related to freebsd but i googled a lot and found nothing useful and > don't know where i should ask my question. > > i want to know how can i calculate the number of ip addresses in a > range? for example if i have 192.0.0.1 192.100.255.254 with mask 8, > how many ip addresses are available in this range? is there any > formula to calculate the number of ip addresses for any range? > i have 192.0.0.1 192.100.255.254 with mask 8 This doesn't mean anything ? There are few tools to deal with ip addresses, you can study the code : python: IPy https://github.com/haypo/python-ipy perl : ipcalc: /usr/ports/net-mgmt/ipcalc ... Basically, an ip address is just a number. IPy associates also a prefix length in an "IP" object. So it can represent a host or a network which is nice. Regards. From owner-freebsd-net@FreeBSD.ORG Thu Aug 8 12:12:03 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A6A7131B for ; Thu, 8 Aug 2013 12:12:03 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 6E9FF2D42 for ; Thu, 8 Aug 2013 12:12:03 +0000 (UTC) Received: from Mail-PC.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id r78CBsa6006937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 8 Aug 2013 13:11:55 +0100 (BST) Date: Thu, 08 Aug 2013 13:11:58 +0100 From: Karl Pielorz To: freebsd-net@FreeBSD.org Subject: Create CARP interface in state INIT? Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 12:12:03 -0000 Hi, I've got a 9.1 box that has CARP setup on it. As it's a mysql server I need to be very careful over CARP interfaces. Is there any way from rc.conf of creating a carp interface in the 'down' state - i.e. INIT? That way if the box reboots we can be confident that whilst the interface will be 'setup' it will not come up at all, *even if* the other MASTER has gone away. I noticed in the 9.1 release notes there's the ability to force a state of BACKUP or MASTER - but I can't seem to force a state of INIT, or down? Thanks, -Karl From owner-freebsd-net@FreeBSD.ORG Thu Aug 8 13:17:59 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9EC3D904 for ; Thu, 8 Aug 2013 13:17:59 +0000 (UTC) (envelope-from darrenr@netbsd.org) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5A5CC219A for ; Thu, 8 Aug 2013 13:17:59 +0000 (UTC) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id AA7C220DBB; Thu, 8 Aug 2013 09:17:57 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Thu, 08 Aug 2013 09:17:57 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:reply-to :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=2/ATuETxOA7SMDbTu3bvZK wD92k=; b=kdL+BGSUS4BGwbXOo2P3nPGZb2i2AFHdU89fnCXUM1ZyArCR8HDQi7 khlxyYMLnORQTkJRy2D9PY1G6w2qYRdoiD7D4GF0gqLRFG0AE7c2el80NyCrtFL8 0W3E+uEhtTycX7gdLfw/1mrZ60FiZwEyKDak9hzKaHHVhpC9cTL08= X-Sasl-enc: qMdkMLLxgLi2CG89jHqkzNIKc/Cqt2IOxtpqi6TgOCu5 1375967877 Received: from [172.20.10.2] (unknown [110.144.139.235]) by mail.messagingengine.com (Postfix) with ESMTPA id E8DCD6801B8; Thu, 8 Aug 2013 09:17:55 -0400 (EDT) Message-ID: <52039B3C.1070509@netbsd.org> Date: Thu, 08 Aug 2013 23:21:00 +1000 From: Darren Reed Organization: NetBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Mindaugas Rasiukevicius Subject: Re: BPF_MISC+BPF_COP and BPF_COPX References: <20130804191310.2FFBB14A152@mail.netbsd.org> <5202693C.50608@netbsd.org> <20130807175548.1528014A21F@mail.netbsd.org> <5203535D.2040508@netbsd.org> <20130808111501.1974C14A2B0@mail.netbsd.org> In-Reply-To: <20130808111501.1974C14A2B0@mail.netbsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tech-net@netbsd.org, guy@alum.mit.edu, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: darrenr@netbsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 13:17:59 -0000 On 8/08/2013 9:14 PM, Mindaugas Rasiukevicius wrote: > Darren Reed wrote: >>> >>> You do not have to use it. >> >> I get no choice - it is in the kernel by default. >> > > There is no default coprocessor. Here is your choice: do not call > bpf_set_cop(9) and those instructions will effectively be NOPs. Anyone with the required privileges to run tcpdump can set this coprocessor. >> <...> >> >> No. It's not about calling a function, it is about proving the BPF >> program is correct and secure. >> >> BPF today is essentially assembly language operations that are all >> easily tested and verified. >> >> <...> >> >> On 8/08/2013 5:18 AM, Joerg Sonnenberger wrote: >>> On Thu, Aug 08, 2013 at 01:35:24AM +1000, Darren Reed wrote: >>>> A BPF program is an entity that can be verified as correct from a >>>> security perspective.It is also self contained and requires no >>>> external references in order to understand. >>> >>> How is this relevant for the discussion? >> >> It is important to understand what BPF is before making changes to it. >> ... > The reason why we have bpf_validate(9) is to ensure that the byte-code > cannot cause any harm to the kernel (whether it is an infinite loop, a > crash or any other security vulnerability), because it is passed from > the *user*. At present it is impossible for there to be an infinite loop because it always branches/jumps forward, thus preventing looping behaviour. It is this very strictness that makes BPF work and worthwhile. Without that, it may as well be Java or some other byte code language. >>>> Then add BPF instructions to manipulate address sets (add, remove, >>>> lookup) and pick a datastore to use to support it. >>> >>> How is that more useful than the proposal? >> >> Actually, add/remove are not instructions for the BPF language, >> only lookup. Add, remove, etc, would be handled in the usual manner. >> >> How is that more useful? > > You contradict yourself here. It still calls some "external reference" > which you are arguing against. Ok, I'll un-contradict myself: it shouldn't be possible for BPF to consist of mneumonics that are function calls that work on the packet rather than operations on the registers/memory. If I implied that this was ok then I was wrong. Have you presented why this approach that you've embarked on is required and others do not work? Is it trying to deal with a limitation/problem in npf? Darren From owner-freebsd-net@FreeBSD.ORG Thu Aug 8 14:18:22 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E24D1CC6 for ; Thu, 8 Aug 2013 14:18:21 +0000 (UTC) (envelope-from rmind@netbsd.org) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CBBD52627 for ; Thu, 8 Aug 2013 14:18:21 +0000 (UTC) Received: from ws (localhost [IPv6:::1]) by mail.netbsd.org (Postfix) with SMTP id 103DB14A2AA; Thu, 8 Aug 2013 14:18:18 +0000 (UTC) Date: Thu, 8 Aug 2013 15:17:59 +0100 From: Mindaugas Rasiukevicius To: darrenr@netbsd.org Subject: Re: BPF_MISC+BPF_COP and BPF_COPX In-Reply-To: <52039B3C.1070509@netbsd.org> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <5202693C.50608@netbsd.org> <20130807175548.1528014A21F@mail.netbsd.org> <5203535D.2040508@netbsd.org> <20130808111501.1974C14A2B0@mail.netbsd.org> <52039B3C.1070509@netbsd.org> X-Mailer: mail(1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20130808141819.103DB14A2AA@mail.netbsd.org> Cc: tech-net@netbsd.org, guy@alum.mit.edu, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 14:18:22 -0000 Darren Reed wrote: > On 8/08/2013 9:14 PM, Mindaugas Rasiukevicius wrote: > > Darren Reed wrote: > >>> > >>> You do not have to use it. > >> > >> I get no choice - it is in the kernel by default. > >> > > > > There is no default coprocessor. Here is your choice: do not call > > bpf_set_cop(9) and those instructions will effectively be NOPs. > > Anyone with the required privileges to run tcpdump can set this > coprocessor. You got it wrong. Sorry if I was not clear, I will try to clarify it again: each BPF user (caller) in the *kernel* would have its own *independent* context (state). Some user(s) might set and use the coprocessor, while the others (kernel part providing /dev/bpf) might not use it. They would not affect each other. There is no way to set the coprocessor at the userlevel (with libpcap or whatever) if there is no kernel code supporting that. > >> > >> It is important to understand what BPF is before making changes to it. > >> > ... > > The reason why we have bpf_validate(9) is to ensure that the byte-code > > cannot cause any harm to the kernel (whether it is an infinite loop, a > > crash or any other security vulnerability), because it is passed from > > the *user*. > > At present it is impossible for there to be an infinite loop because > it always branches/jumps forward, thus preventing looping behaviour. > > It is this very strictness that makes BPF work and worthwhile. > > Without that, it may as well be Java or some other byte code language. What kind of strictness are you talking about? Previously you were talking about security, now about the capability of the BPF byte-code. The coprocessor support provides offloading capability. It does not add looping capability and no - it does not change BPF to be Turing-complete. If your point was that we should not consider improvements and conserve the instruction set from 80s, then we simply disagree. :) > >> Actually, add/remove are not instructions for the BPF language, > >> only lookup. Add, remove, etc, would be handled in the usual manner. > >> > >> How is that more useful? > > > > You contradict yourself here. It still calls some "external reference" > > which you are arguing against. > > Ok, I'll un-contradict myself: > it shouldn't be possible for BPF to consist of mneumonics that are > function calls that work on the packet rather than operations on the > registers/memory. If I implied that this was ok then I was wrong. Can you provide a justification for this? > Have you presented why this approach that you've embarked on is > required and others do not work? It provides way much greater flexibility, or rather - it provides the flexibility, while your solution does not. > > Is it trying to deal with a limitation/problem in npf? Not at all. This is to avoid code duplication. It is BPF which has a limitation and BPF_COP is a clean way (design wise) to address it. -- Mindaugas From owner-freebsd-net@FreeBSD.ORG Thu Aug 8 15:44:42 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C81285A9 for ; Thu, 8 Aug 2013 15:44:42 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8C7CA2D71 for ; Thu, 8 Aug 2013 15:44:42 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id w15so2112703iea.33 for ; Thu, 08 Aug 2013 08:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=8mobwuPc7LEtM5GJ19Bd8uJbfSDxX8M5fOI4EnznrO8=; b=I2GiBeWkQC0hMLf70ylAEk2ErusCHW2SZQ88RHNyi56b2eY2yo48Iw0iauMaoWXT4Z GjTsiw9coXPTwf/iQ8q+SmH1XJsEGgehygEiwKur/AajFn8NaflRUnb1C7q1sXeyI4xF Fa0AT0D1RohS57LUt/Is4W4Hr5LQTkjTwHqfE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=8mobwuPc7LEtM5GJ19Bd8uJbfSDxX8M5fOI4EnznrO8=; b=B+uIJWykANsGL+3soyDElVry8QbMQr11S3+IGPKxzMfKEktI/Y94cvNON/0np8qo6T ifv6O+SnNrV1W5S3HZmUChAtuEIq3ljS26C6GzXio0V8TRG6LC0bDXMk59RzawdymMxI bgpsSRTuen8cqKxlpTLf15X5RKrfji0UHVexLG7hNf+35WCDFhc8e0wcKAjIuy2w+f9w NlL2nrxcJso0h3pPD345kaqB8AYJENd04K40XqcnqXZp+eGV7gHGG235DA4EDWxzYxhN iZqjYAhiNen3REK6kYsplqinb/62wwE8ho37X7haiGfakOEcuuoFDtSB2I/jLNx+MbPQ PAag== X-Gm-Message-State: ALoCoQmCDs/XqNoKuf4pbNyhalCmyE4f1Wvr+mV4yjYGir7bmKl0lS2sGuRoJ71EJzpii2dJPZp+ X-Received: by 10.43.144.82 with SMTP id jp18mr2393400icc.100.1375976681954; Thu, 08 Aug 2013 08:44:41 -0700 (PDT) Received: from [192.168.31.77] (97-92-62-100.dhcp.aldl.mi.charter.com. [97.92.62.100]) by mx.google.com with ESMTPSA id fu2sm6731264igb.3.2013.08.08.08.44.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 Aug 2013 08:44:40 -0700 (PDT) References: <20130808133055.15e53b94@davenulle.org> Mime-Version: 1.0 (1.0) In-Reply-To: <20130808133055.15e53b94@davenulle.org> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3C7A0216-480F-47F2-9869-3822FD473C26; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <1F113410-18DE-47CF-96C1-5EE4E8BC4980@dataix.net> X-Mailer: iPhone Mail (10B350) From: Jason Hellenthal Subject: Re: how calculate the number of ip addresses in a range? Date: Thu, 8 Aug 2013 11:44:37 -0400 To: Patrick Lamaiziere X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net , s m X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 15:44:42 -0000 --Apple-Mail-3C7A0216-480F-47F2-9869-3822FD473C26 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Try subcalc, it's in ports. --=20 Jason Hellenthal Inbox: jhellenthal@DataIX.net Voice: +1 (616) 953-0176 JJH48-ARIN On Aug 8, 2013, at 7:30, Patrick Lamaiziere wrote: > Le Thu, 8 Aug 2013 11:34:22 +0430, > s m a =C3=A9crit : >=20 >> hello guys, >>=20 >> i have a question about ip addresses. i know my question is not >> related to freebsd but i googled a lot and found nothing useful and >> don't know where i should ask my question. >>=20 >> i want to know how can i calculate the number of ip addresses in a >> range? for example if i have 192.0.0.1 192.100.255.254 with mask 8, >> how many ip addresses are available in this range? is there any >> formula to calculate the number of ip addresses for any range? >=20 >> i have 192.0.0.1 192.100.255.254 with mask 8 >=20 > This doesn't mean anything ? >=20 > There are few tools to deal with ip addresses, you can study the code : > python: IPy https://github.com/haypo/python-ipy > perl : ipcalc: /usr/ports/net-mgmt/ipcalc > ... >=20 > Basically, an ip address is just a number. IPy associates also a > prefix length in an "IP" object. So it can represent a host or > a network which is nice. >=20 > Regards. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" --Apple-Mail-3C7A0216-480F-47F2-9869-3822FD473C26 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgwODE1NDQzOVowIwYJKoZIhvcN AQkEMRYEFE4+2yCRze9rtHEhh5cD7QDFkVuFMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEAZZBwKWW2iFhFVzBOHG7t zE4VvMjdEVF0Kkh0YNOS5vpRMM8XoZWcG7blm/I1I1DfePNYAsd+FyrmTyUmTXdoGymj49YKg3jV qGn56t6LKBczcg9bma8Qdebv7nt3sDGi7YpRQCvvWml/sP/bg3CscBRpiOdX/SkHG2DEKoNJnc1V l4YWEz91qa83y/pUQZMsihGunXLxz2xl1cG1rAI5SzeP8q48p7QHuzYnu6LuCqS2ztY40UCLIL+m ICXIBJ/6jWLVa4r11kulaNS0JMZAwt0FLSnlFgEao2aevwKE10EenQP/6/u6e6AVquWNqMs7Wbux 28NiHzGBxidgTzcdfwAAAAAAAA== --Apple-Mail-3C7A0216-480F-47F2-9869-3822FD473C26-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 8 15:54:02 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 522C39E2 for ; Thu, 8 Aug 2013 15:54:02 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 26A322E26 for ; Thu, 8 Aug 2013 15:54:01 +0000 (UTC) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id E944A20B30 for ; Thu, 8 Aug 2013 11:54:00 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute6.internal (MEProxy); Thu, 08 Aug 2013 11:54:00 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=U9UKMo5g5LoR27aXw7GcK3GgIgk=; b=ACp FdGkuWJ7HVFh6AC/qKkPJO9DQftO7GsCdkUykdjPmnLjinBtg9h+ymqgVKA8yLhH 6fP259SZ8fbKJ8BB1moLEfTtp5jb0VC/xQdySmuj5UOnW1Esi7IPIEl7pt4oZqYr aMWFSbFH2QJVD2+PsOJfHS0EJ0zCLuh5TUY7/jwE= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id BDD4BB022F6; Thu, 8 Aug 2013 11:54:00 -0400 (EDT) Message-Id: <1375977240.3930.7571559.74F89736@webmail.messagingengine.com> X-Sasl-Enc: oYevjTCqoYonTvfJiJxdqAvtEz4thdui89MZwToJwr/F 1375977240 From: Mark Felder To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-d9f253bf In-Reply-To: <1F113410-18DE-47CF-96C1-5EE4E8BC4980@dataix.net> References: <20130808133055.15e53b94@davenulle.org> <1F113410-18DE-47CF-96C1-5EE4E8BC4980@dataix.net> Subject: Re: how calculate the number of ip addresses in a range? Date: Thu, 08 Aug 2013 10:54:00 -0500 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 15:54:02 -0000 On Thu, Aug 8, 2013, at 10:44, Jason Hellenthal wrote: > Try subcalc, it's in ports. > I always kept ipcalc installed, but it looks like there's another called sipcalc, too. I'll have to check these out myself and see if any have merits over each other. From owner-freebsd-net@FreeBSD.ORG Thu Aug 8 15:55:46 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 02133B59 for ; Thu, 8 Aug 2013 15:55:46 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C06C02E53 for ; Thu, 8 Aug 2013 15:55:45 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id h1so5413078oag.24 for ; Thu, 08 Aug 2013 08:55:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pMdx1HtpSMK9CIHxr1y9gviqM1etjjVcGZGomZxYBPw=; b=NmILy5epdzXnlTkJCF78hUAHD/BCnuXnQu0PmiF/agK6XuGAYA0mOn7eMQEJg+/gyl W1546TqL4l5bv4zUEVNXHHpGnQfU/N+ffHMfuxvDDNcOL4S3nJR5TouQUvjv/ApVXpgD xiJWf74UxsQqKSktmB2ZlejksU075CULRFyk+zI/YciCm3+z1Zo1Jyh3sNNCQo981Pnd jiLbv2NyucSss+QBXzLZNY/PFGaqxu1rXej4iaeXEghYxPp3PtwyR5GUsBjIVp6Ya4NY fE8xuiBCzaovcxfXL9YNv2O6M8nMnNobDMCCTtTkyVfgbNFAaCtXIwSNgOccl2YEXyp+ 2FBQ== X-Gm-Message-State: ALoCoQlKwg0/o9t0GfjWisW6pNS8st/rDfEvm1uCTFKV2K2lDpmoh0yGtVZwl+Mvo4pjkE1AsSuC MIME-Version: 1.0 X-Received: by 10.182.171.74 with SMTP id as10mr6687674obc.70.1375977338909; Thu, 08 Aug 2013 08:55:38 -0700 (PDT) Received: by 10.60.21.69 with HTTP; Thu, 8 Aug 2013 08:55:38 -0700 (PDT) In-Reply-To: <1375977240.3930.7571559.74F89736@webmail.messagingengine.com> References: <20130808133055.15e53b94@davenulle.org> <1F113410-18DE-47CF-96C1-5EE4E8BC4980@dataix.net> <1375977240.3930.7571559.74F89736@webmail.messagingengine.com> Date: Thu, 8 Aug 2013 08:55:38 -0700 Message-ID: Subject: Re: how calculate the number of ip addresses in a range? From: Michael Sierchio To: Mark Felder Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 15:55:46 -0000 pkg_add -r ipsc > ipsc -gch 10.80.128.0/27 Network class: A Network mask: 255.0.0.0 Network mask (hex): FF000000 Network address: 10.80.128.0 Subnet bits: 19 Max subnets: 524288 Full subnet mask: 255.255.255.224 Full subnet mask (hex): FFFFFFE0 Host bits: 5 Addresses per subnet: 32 Bit map: nnnnnnnn.ssssssss.ssssssss.ssshhhhh IP address: 10.80.128.0 Hexadecimal IP address: A508000 Host allocation range: 10.80.128.1 - 10.80.128.30 Full subnet mask: 255.255.255.224 Subnet mask: 0.255.255.224 Subnet ID: 0.80.128.0 Network ID: 10.0.0.0 Host ID: 0.80.128.0 CIDR notation: 10.0.0.0 /27 Supernet max: 0 Cisco wildcard: 0.0.0.31 Classful network: 10.0.0.0 /8 Route/Mask: 10.0.0.0 / 255.255.255.224 Hexadecimal route/mask: A000000 / FFFFFFE0 On Thu, Aug 8, 2013 at 8:54 AM, Mark Felder wrote: > On Thu, Aug 8, 2013, at 10:44, Jason Hellenthal wrote: >> Try subcalc, it's in ports. >> > > I always kept ipcalc installed, but it looks like there's another called > sipcalc, too. I'll have to check these out myself and see if any have > merits over each other. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Aug 8 17:29:02 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 21361C26 for ; Thu, 8 Aug 2013 17:29:02 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm49-vm4.bullet.mail.gq1.yahoo.com (nm49-vm4.bullet.mail.gq1.yahoo.com [67.195.87.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CE75726B6 for ; Thu, 8 Aug 2013 17:29:01 +0000 (UTC) Received: from [216.39.60.181] by nm49.bullet.mail.gq1.yahoo.com with NNFMP; 08 Aug 2013 17:23:21 -0000 Received: from [98.136.164.77] by tm17.bullet.mail.gq1.yahoo.com with NNFMP; 08 Aug 2013 17:23:21 -0000 Received: from [127.0.0.1] by smtp239.mail.gq1.yahoo.com with NNFMP; 08 Aug 2013 17:23:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1375982601; bh=HHyIreysPKOMyVa85kxfnCcsv9XcN3hRbm0UAG49ri0=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=R5MySjQhs9Ba95g/0Ofay/MYPmB89ldB85S09S4F87AbrE7f9BsMRxSKW3UltBTsPlFqtSPG1k6tZG2+OpMKckVfiydRjyhjKH8BStu6vrFL2FZ03+hPU0dnHDvrqdRr/Q+e+MUQcUEOUgAHdm7ujwFy1YDX2K/xR+KsVyf6eIg= X-Yahoo-Newman-Id: 124328.76621.bm@smtp239.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: icbtmfQVM1mMOJGwJdkQUTE60iZh8Je.6qTqkqCu1WxdEU. z8Wtun6FiHsxHJJ.VaTGXgLxFASl7Y3WoRNjql4J1W9tkn4oSMTZlEpvcBhh eDtdEY6CObvHdQ6EAnNI6Kqq62k9bdz80jLB3PrWYWGbmPFyDDGjJURWdUGt t8jEAJSOmOQOYh9YJfjHWPiQAetWIWMOg6IbyMtpD5Y1jz6BxxsECLAre1Ig 7Vru5b0Lg5cPCucicZCA4q8bCnXIxCy2jB7S63u.WsuhdQtv8laxhwf9iCBC N5pIzdt50YOHu8RmsQUGLHVdqjJKt83ArkBd_egL4itdnrEYxC2hMmkOt9MM TDXaezsQEaWvYZkZT3dKJetJe7WGCF25y8HIqqgaqVg1AzSu4a4Vr.E65cPj 0KkTdnkZXrZ9bHy5BUxQ8.eoCpxSnAKA3e_Tq7KW_EsNlaUL9PONStjq4Udp ploME_ZEwCycv5UPmGRmWy7FJDa.41D5wHq2R841U64gKECYeEfRJvH_SgSh FM35hpLpYXkjrUcEK6mn69aqFo_UnXvm4FD8GHKhrWlYZyI.f8WHruBEdbfK j X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- X-Rocket-Received: from phobos.corp.netflix.com (scott4long@69.53.237.66 with ) by smtp239.mail.gq1.yahoo.com with SMTP; 08 Aug 2013 17:23:20 +0000 UTC Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [net] protecting interfaces from races between control and data ? From: Scott Long In-Reply-To: Date: Thu, 8 Aug 2013 10:23:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3BFB5B13-78C5-47E0-81B8-29A03A0136DF@yahoo.com> References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> To: Warner Losh X-Mailer: Apple Mail (2.1508) Cc: Adrian Chadd , current@freebsd.org, Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri , Luigi Rizzo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 17:29:02 -0000 On Aug 7, 2013, at 10:16 PM, Warner Losh wrote: >=20 > On Aug 5, 2013, at 11:20 AM, Adrian Chadd wrote: >=20 >> .. and I bet it's not a design pattern, and this is total conjecture = on my part: >>=20 >> * the original drivers weren't SMP safe; >> * noone really sat down and figured out how to correctly synchronise >> all of this stuff; >> * people did the minimum amount of work to keep the driver from >> immediately crashing, but didn't really think things through at a >> larger scale. >>=20 >> Almost every driver is this way Luigi. :-) >=20 > Most of the drivers in the three don't support hardware that performs = well enough for this to be a problem. :) Any driver that's still around = from the pre-locking days can easily saturate the lines (or the = hardware) on today's (and even yesterday's hardware). >=20 > All the rest have come up with different ways to cope=85 >=20 Not really. So the typical pattern is: foo_rxeof() { =85. FOO_UNLOCK(sc); ifp->if_input(ifp, m); FOO_LOCK(sc); =85. } Grepping for an approximation of this pattern: [nflx1] ~/svn/head/sys/dev% grep -r -B 5 if_input * | grep -i UNLOCK | = cut -d '/' -f 1 ae age alc ale an an bce bfe bge bm cadence cas cas dc de e1000 e1000 e1000 ed ep et ex fe fxp gem gxemul hme ie ixgb ixgbe ixgbe jme le le lge mge msk msk my nfe nfe nge nve pcn pdq re sbni sf sge sis sk sk sn snc ste stge ti tl tsec tx txp usb usb vge virtio vr vte vx wb wl xe xl Sure a lot of these are very legacy. But there's a lot in here's that = are not. bge, bce, e1000, ixgbe, virtio, etc, probably more that I'm = not catching in this quick pass. Scott From owner-freebsd-net@FreeBSD.ORG Thu Aug 8 19:23:47 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 026B5E36 for ; Thu, 8 Aug 2013 19:23:47 +0000 (UTC) (envelope-from bsd-lists@1command.com) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C40722D8B for ; Thu, 8 Aug 2013 19:23:45 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id r78JO12o042978; Thu, 8 Aug 2013 12:24:07 -0700 (PDT) (envelope-from bsd-lists@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id r78JNuIV042975; Thu, 8 Aug 2013 12:23:56 -0700 (PDT) (envelope-from bsd-lists@1command.com) Received: from udns.ultimatedns.net ([209.180.214.225]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Thu, 8 Aug 2013 12:23:56 -0700 (PDT) Message-ID: <66d93d2596e3eb463723c56c58756592.authenticated@ultimatedns.net> In-Reply-To: References: Date: Thu, 8 Aug 2013 12:23:56 -0700 (PDT) Subject: Re: how calculate the number of ip addresses in a range? From: "Chris H" To: "s m" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 19:23:47 -0000 > hello guys, > > i have a question about ip addresses. i know my question is not related to > freebsd but i googled a lot and found nothing useful and don't know where i > should ask my question. > > i want to know how can i calculate the number of ip addresses in a range? > for example if i have 192.0.0.1 192.100.255.254 with mask 8, how many ip > addresses are available in this range? is there any formula to calculate > the number of ip addresses for any range? > > i'm confusing about it. please help me to clear my mind. > thanks in advance, > SAM Aside from many ports available in the ports/net* categories that provide calculators, and such. You can use an online version @: http://ultimatedns.net/netcalc HTH --chris > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu Aug 8 21:47:00 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C951DF3F; Thu, 8 Aug 2013 21:47:00 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9568F2585; Thu, 8 Aug 2013 21:47:00 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 136B637B4A6; Thu, 8 Aug 2013 16:46:53 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3cB37w3TVyz9jM; Thu, 8 Aug 2013 16:46:52 -0500 (CDT) Date: Thu, 8 Aug 2013 16:46:52 -0500 From: "Matthew D. Fuller" To: Michael Sierchio Subject: Re: how calculate the number of ip addresses in a range? Message-ID: <20130808214652.GZ34979@over-yonder.net> References: <20130808133055.15e53b94@davenulle.org> <1F113410-18DE-47CF-96C1-5EE4E8BC4980@dataix.net> <1375977240.3930.7571559.74F89736@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.21-fullermd.4 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.8 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: "freebsd-net@freebsd.org" , Mark Felder X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 21:47:00 -0000 On Thu, Aug 08, 2013 at 08:55:38AM -0700 I heard the voice of Michael Sierchio, and lo! it spake thus: > > pkg_add -r ipsc For another, there's a "cidrcalc" program installed by devel/libcidr (full disclosure: of which I'm the author) that does similar things: % cidrcalc -bs 10.80.128.35/27 Address: 10.80.128.35 Netmask: 255.255.255.224 (/27) BinAddr: 00001010 01010000 10000000 00100011 10 80 128 35 BinMask: 11111111 11111111 11111111 11100000 255 255 255 224 Wildcard: 0.0.0.31 Network: 10.80.128.32/27 Broadcast: 10.80.128.63 Hosts: 10.80.128.33 - 10.80.128.62 NumHosts: 30 Supernet: 10.80.128.0/26 Subnets: 10.80.128.32/28 10.80.128.48/28 -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-net@FreeBSD.ORG Thu Aug 8 22:30:41 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 14B7615D for ; Thu, 8 Aug 2013 22:30:41 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C256927F3 for ; Thu, 8 Aug 2013 22:30:40 +0000 (UTC) Received: by mail-vc0-f181.google.com with SMTP id hz10so549249vcb.12 for ; Thu, 08 Aug 2013 15:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=819tV5gfItjgVWuY9uoqDFYwCbWz85uZzGhZwJTsy9Y=; b=UESf9Ynyf2957XosfD4HfT8GlRsOwT2+J6uDnQXGoyeEqCF7BULz2Y6tvnTHi9Dpd4 wrgHzf1wkL8mfysn6JrG+aA4UEdc9AYe1t0FJyB4HfB2AKhAjY3RPdhh454EBA0eRbfc SOwr/ZjG2EhgRa+2tf4hvCAdfJqrzlzNsYLwo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=819tV5gfItjgVWuY9uoqDFYwCbWz85uZzGhZwJTsy9Y=; b=FR2Vsug6B71kP3ME6FCcacGFBb+isCA8Io46rE1dZFw7PI5RiKkaTWpD88g+g7o9lk CJW6PZUeOP37VX+xheWDphI++kWHaSB6thElBNIaVOKT0gA6bwWMBY0P/9qHsCtTznzc BWnvEudHexTPGbK4laAnohWbgJExSYGxyG3JKum5l7VZkNtpRjtvpwcqxX8gu1Ki4DGF tK/rNT2bXCNqTKH+/MoB59c1GiJPiouTWojVONDryCGHqUuTpYAYtIVIkXHlWAn1IuHp z0g04OXc4x69km2aCsVs4eZyhzGlBr8wv1IvRHsS+ajUH3yis8VzvNWfa53tmGFk9K83 P4qA== X-Gm-Message-State: ALoCoQnkRY+PXy2ZDkddWCjh8aF+Sm1xZfp2mShlDBz6sPmpMs1pTWEdl+KX5l4bDkoT5TV5FhNE MIME-Version: 1.0 X-Received: by 10.220.50.10 with SMTP id x10mr3374544vcf.86.1376001039946; Thu, 08 Aug 2013 15:30:39 -0700 (PDT) Received: by 10.220.167.74 with HTTP; Thu, 8 Aug 2013 15:30:39 -0700 (PDT) In-Reply-To: <20130808214652.GZ34979@over-yonder.net> References: <20130808133055.15e53b94@davenulle.org> <1F113410-18DE-47CF-96C1-5EE4E8BC4980@dataix.net> <1375977240.3930.7571559.74F89736@webmail.messagingengine.com> <20130808214652.GZ34979@over-yonder.net> Date: Thu, 8 Aug 2013 15:30:39 -0700 Message-ID: Subject: Re: how calculate the number of ip addresses in a range? From: Peter Wemm To: "Matthew D. Fuller" Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" , Michael Sierchio , Mark Felder X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 22:30:41 -0000 On Thu, Aug 8, 2013 at 2:46 PM, Matthew D. Fuller wrote: > On Thu, Aug 08, 2013 at 08:55:38AM -0700 I heard the voice of > Michael Sierchio, and lo! it spake thus: >> >> pkg_add -r ipsc > > For another, there's a "cidrcalc" program installed by devel/libcidr > (full disclosure: of which I'm the author) that does similar things I still suspect he was asking for somebody to do his homework for him. A third party tool doesn't work for that. He needs the math for it. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV UTF-8: for when a ' just won\342\200\231t do. ZFS must be the bacon of file systems. "everything's better with ZFS" From owner-freebsd-net@FreeBSD.ORG Fri Aug 9 00:18:05 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 042A5523; Fri, 9 Aug 2013 00:18:05 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3B0922D8E; Fri, 9 Aug 2013 00:18:04 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id f14so1156256wiw.9 for ; Thu, 08 Aug 2013 17:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ryT471CEcueqAct/PHx4mW01uzOKrrCQHiEFTpaBDS4=; b=HDjHBg6Q/yR76LCIZibAKP+dua5gRdpz229xpPRlYsXNPhX4rzeOumvgg8KEaN/Kb3 7xlNxCFbcejThOrflmubwj6DTfFcr/faEfWuojzZRH5oGE3Iu8gS2I7TrwIxMpv5MwbY Z6FpDY4K0IhgHE8Cd447Gvx4GWcKhZaiNPYCPD4zT9zz4UhqGAUwRgFPh4iljjgKaej7 JFaDJDprSl9Z4URfJ5L3F8Tl0dmpS88qbOm/HWnqs4q4OhDrmEoJb/lWPdqrqs6GSaog nBu5dtF1revVZCWW5aRT3OdXfdHa0KS9JrC8Qg9vVONSssK943I2GWhH5ysgwNRx3hL6 CoMg== MIME-Version: 1.0 X-Received: by 10.180.20.116 with SMTP id m20mr725711wie.46.1376007482502; Thu, 08 Aug 2013 17:18:02 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Thu, 8 Aug 2013 17:18:02 -0700 (PDT) In-Reply-To: <3BFB5B13-78C5-47E0-81B8-29A03A0136DF@yahoo.com> References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> <3BFB5B13-78C5-47E0-81B8-29A03A0136DF@yahoo.com> Date: Thu, 8 Aug 2013 17:18:02 -0700 X-Google-Sender-Auth: qiNC1bW8Lrz-_F72T2yYp9CMzzQ Message-ID: Subject: Re: [net] protecting interfaces from races between control and data ? From: Adrian Chadd To: Scott Long Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org, Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri , Luigi Rizzo , Warner Losh X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 00:18:05 -0000 .. and it's not just about "saturate the port" with traffic. It's also about "what happens if I shut down the MAC whilst I'm in the process of programming in new RX/TX descriptors?" The ath(4) driver had a spectacular behaviour where if you mess things up the wrong way it will quite happily DMA crap all over the memory of your running system, leading to quite hilarious bugs. -adrian From owner-freebsd-net@FreeBSD.ORG Fri Aug 9 00:27:05 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3699E7FB for ; Fri, 9 Aug 2013 00:27:05 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm30-vm6.bullet.mail.gq1.yahoo.com (nm30-vm6.bullet.mail.gq1.yahoo.com [98.136.216.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EDB882E36 for ; Fri, 9 Aug 2013 00:27:04 +0000 (UTC) Received: from [98.137.12.61] by nm30.bullet.mail.gq1.yahoo.com with NNFMP; 09 Aug 2013 00:20:14 -0000 Received: from [98.136.164.73] by tm6.bullet.mail.gq1.yahoo.com with NNFMP; 09 Aug 2013 00:20:14 -0000 Received: from [127.0.0.1] by smtp235.mail.gq1.yahoo.com with NNFMP; 09 Aug 2013 00:20:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1376007614; bh=zHiSK3cA2cIM0tWIXhDDYOiqAkerWT5Y2BByeVW57Rw=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=5r/hxZTQmPPt9qsgOAKNzTTkRiepNR/zNKY70/0olVC7ZK4zeVZvVJ5IJUILxpscbXR7oU2PmMUEtVfLPO16EC+lc34VjMO3rOq8I/3kehYNF4stUU95etrhfgbw9zzZL9Ec2y7CI7zPAM7JDVDRhsAjny6RjECK/5gtuy7XRbY= X-Yahoo-Newman-Id: 99189.72728.bm@smtp235.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: JAxQ.LcVM1m_YU5BLf2rywnEtJMnNWaYwjT6PEB5QfhPM.D PA.pSf56VX0g_vdYk8flQpJuVVAKPVQcGoBnWMSDAUvWLGUAtrdnkt_ld95N lraeWfUvS7hs_hr5nHw3mdWGiAp.KaDlhwwznEdoR5hcDIpCzCG1mdYQdxjt 2ybae_Vky.NxoXF.7zm50bLTe2NcLi_wdQX_aSxYqMwj8PFpJsk8RfG97Ev0 1ZVo0NWjPg.22G0O6eesLwBCPBbdMzxxge0pQ5UK6zKciL64khfMM5hN9duu wJJylcGNEpSk37sZOksMxE_oWp.4P1SZFgz7cTTJmUdZGpsmLSc0hg17jg42 sdN8QOeiMqxnuVMUBvmzW_qn_URWK_RNZCkVJ9bkTDscYgkSQu0DJmLnxkDS cA_ANpy.fKK3Vg9R7rdMqqyKlbGsO55yrLcqZKkdCeldAIAsf5teNFEpcB8U UT4HTOXB3YaQQvjHeK9vIr4fhG5BekY8qcye3PIqoGvzzRGGe5jlTeHq1doH Uno_Ncd1IHv_Rv7Y9sUWUUisiLMbm1m9OGJzZOV4Kczo03ql8H8gWTdxv X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- X-Rocket-Received: from phobos.corp.netflix.com (scott4long@69.53.237.66 with ) by smtp235.mail.gq1.yahoo.com with SMTP; 09 Aug 2013 00:20:13 +0000 UTC Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: [net] protecting interfaces from races between control and data ? From: Scott Long In-Reply-To: Date: Thu, 8 Aug 2013 17:20:13 -0700 Content-Transfer-Encoding: 7bit Message-Id: <0068D32B-C900-47EB-8E82-C50506AB1F6D@yahoo.com> References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> <3BFB5B13-78C5-47E0-81B8-29A03A0136DF@yahoo.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1508) Cc: current@freebsd.org, Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri , Luigi Rizzo , Warner Losh X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 00:27:05 -0000 Yup, it's an incredibly unsafe pattern. It also leads to the pattern where auxiliary processing is handed off to a taskqueue, which then interleaves the lock ownership with the ithread and produces out-of-order packet reception. Scott On Aug 8, 2013, at 5:18 PM, Adrian Chadd wrote: > .. and it's not just about "saturate the port" with traffic. > > It's also about "what happens if I shut down the MAC whilst I'm in the > process of programming in new RX/TX descriptors?" > > The ath(4) driver had a spectacular behaviour where if you mess things > up the wrong way it will quite happily DMA crap all over the memory of > your running system, leading to quite hilarious bugs. > > > > -adrian From owner-freebsd-net@FreeBSD.ORG Fri Aug 9 01:27:15 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 52BAF83D; Fri, 9 Aug 2013 01:27:15 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 25BF521A0; Fri, 9 Aug 2013 01:27:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r791RE2Q035079; Fri, 9 Aug 2013 01:27:14 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r791REG5035078; Fri, 9 Aug 2013 01:27:14 GMT (envelope-from linimon) Date: Fri, 9 Aug 2013 01:27:14 GMT Message-Id: <201308090127.r791REG5035078@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/181135: [netmap] [patch] sys/dev/netmap patch for Linux compatibility X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 01:27:15 -0000 Old Synopsis: sys/dev/netmap patch for Linux compatibility New Synopsis: [netmap] [patch] sys/dev/netmap patch for Linux compatibility Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Aug 9 01:26:45 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=181135 From owner-freebsd-net@FreeBSD.ORG Fri Aug 9 01:29:32 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6686A9A6; Fri, 9 Aug 2013 01:29:32 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 38E1621C5; Fri, 9 Aug 2013 01:29:32 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r791TWf2035320; Fri, 9 Aug 2013 01:29:32 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r791TWRf035319; Fri, 9 Aug 2013 01:29:32 GMT (envelope-from linimon) Date: Fri, 9 Aug 2013 01:29:32 GMT Message-Id: <201308090129.r791TWRf035319@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/181131: [netmap] [patch] sys/dev/netmap memory allocation improvement X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 01:29:32 -0000 Old Synopsis: sys/dev/netmap memory allocation improvement New Synopsis: [netmap] [patch] sys/dev/netmap memory allocation improvement Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Aug 9 01:29:19 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=181131 From owner-freebsd-net@FreeBSD.ORG Fri Aug 9 11:06:43 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EF3DDD30 for ; Fri, 9 Aug 2013 11:06:42 +0000 (UTC) (envelope-from darrenr@netbsd.org) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A880420B7 for ; Fri, 9 Aug 2013 11:06:42 +0000 (UTC) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 2BC9320D4D; Fri, 9 Aug 2013 07:06:41 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 09 Aug 2013 07:06:41 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:reply-to :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=xvdofQoH5aSdgvUG4li5n9 ATn2s=; b=tbn55rEA/YCCOIgsu+IKKxu7xP/2QgZN4y64prx0r5zLlboI4SBzdc OegA8Mj5bcem6ac2NRUWKJOKUrgBFGlZVnQv8qFDV0CG6h7bEfekGRtvF+BkVbBD J3OiTetO1l0X5o8qDU8DPI1iEcQ+hp9xQnArY2yQFt8uW5trIduFI= X-Sasl-enc: OSLreD7EY6GH0HYJzqZn3Yh/ODtni49lWMNAc5qCIohY 1376046400 Received: from [172.20.10.2] (unknown [58.171.193.197]) by mail.messagingengine.com (Postfix) with ESMTPA id 67267C00E82; Fri, 9 Aug 2013 07:06:39 -0400 (EDT) Message-ID: <5204CDFB.6060200@netbsd.org> Date: Fri, 09 Aug 2013 21:09:47 +1000 From: Darren Reed Organization: NetBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Mindaugas Rasiukevicius Subject: Re: BPF_MISC+BPF_COP and BPF_COPX References: <20130804191310.2FFBB14A152@mail.netbsd.org> <5202693C.50608@netbsd.org> <20130807175548.1528014A21F@mail.netbsd.org> <5203535D.2040508@netbsd.org> <20130808111501.1974C14A2B0@mail.netbsd.org> <52039B3C.1070509@netbsd.org> <20130808141819.103DB14A2AA@mail.netbsd.org> In-Reply-To: <20130808141819.103DB14A2AA@mail.netbsd.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tech-net@netbsd.org, guy@alum.mit.edu, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: darrenr@netbsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 11:06:43 -0000 On 9/08/2013 12:17 AM, Mindaugas Rasiukevicius wrote: > Darren Reed wrote: >> On 8/08/2013 9:14 PM, Mindaugas Rasiukevicius wrote: >>> Darren Reed wrote: >>>>> >>>>> You do not have to use it. >>>> >>>> I get no choice - it is in the kernel by default. >>>> >>> >>> There is no default coprocessor. Here is your choice: do not call >>> bpf_set_cop(9) and those instructions will effectively be NOPs. >> >> Anyone with the required privileges to run tcpdump can set this >> coprocessor. > > You got it wrong. Sorry if I was not clear, I will try to clarify > it again. Rather than try explaining it across an email thread, maybe the design should be presented fully and accompany a problem description. >> At present it is impossible for there to be an infinite loop because >> it always branches/jumps forward, thus preventing looping behaviour. >> >> It is this very strictness that makes BPF work and worthwhile. >> >> Without that, it may as well be Java or some other byte code language. > > What kind of strictness are you talking about? Previously you were > talking about security, now about the capability of the BPF byte-code. The strictness that makes it impossible for there to be infinite loops (for example.) That strictness also imparts security. > The coprocessor support provides offloading capability. Yes, it does... > If your point was that we should not consider improvements and conserve > the instruction set from 80s, then we simply disagree. :) No, improvements in BPF are required for IPv6, e.g. http://permalink.gmane.org/gmane.network.tcpdump.devel/5141 >> Ok, I'll un-contradict myself: >> it shouldn't be possible for BPF to consist of mneumonics that are >> function calls that work on the packet rather than operations on the >> registers/memory. If I implied that this was ok then I was wrong. > > Can you provide a justification for this? Because then BPF ceases to be a language that can be verified for security, reliability and performance purposes. >> Is it trying to deal with a limitation/problem in npf? > > Not at all. This is to avoid code duplication. It is BPF which has a > limitation and BPF_COP is a clean way (design wise) to address it. Maybe you should start this proposal properly with a problem description and how this solves it. There isn't nearly enough information in what has been presented to properly understand what has been proposed. Darren From owner-freebsd-net@FreeBSD.ORG Fri Aug 9 16:34:51 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 50DB5737 for ; Fri, 9 Aug 2013 16:34:51 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D82B5227D for ; Fri, 9 Aug 2013 16:34:50 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id hq12so1834140wib.2 for ; Fri, 09 Aug 2013 09:34:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=G0uf3vNF5JLj/0LNoYML7yxC6w6NTSQ5QSpAiJPMQSE=; b=gwYIWMOjF/OGB1gt4G38R2vz4dHi6Ps/mSWzH5vS0TR1MkFeDxBbxFx9Ab1RjYaHM8 0KXtWKX+B6lcWWIiyvEWdepA+uuOGly5onS3asICSwaXVPgVPy6/TOpGsie8KI7alJVS PBI+uI+SpCI6rRbgJncyjcFXytIihkAkxKT7uZPwzVDZGKp9jkv8Otu81B+qjaSG5J17 mzkkyfTMhYADjmHb08jYgh3u7z1qP1mRSYl6b6rp6ApIERXqjknIE4p/GTxaVxt+cEy3 q7VyXHFbU3z8Vk3XtZwuPtqc1ASa/9T+mKsvisWnLWy4pdUSjOGm3Oy1hXakVgvjnFLz mI5w== X-Gm-Message-State: ALoCoQmCK+sTpacmnhg0IeOiJEQAygilPaxzaVauBWV3YZdb6gqts95M5lIpZW7mPT0veKVtFztF X-Received: by 10.180.13.210 with SMTP id j18mr796364wic.51.1376066083182; Fri, 09 Aug 2013 09:34:43 -0700 (PDT) Received: from dfleuriot.paris.hi-media-techno.com ([83.167.62.196]) by mx.google.com with ESMTPSA id l5sm3730508wia.6.2013.08.09.09.34.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 Aug 2013 09:34:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: how calculate the number of ip addresses in a range? From: Fleuriot Damien In-Reply-To: Date: Fri, 9 Aug 2013 18:34:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8B53C542-5CC3-45E6-AA62-B9F52A735EE5@my.gd> References: To: Peter Wemm X-Mailer: Apple Mail (2.1508) Cc: FreeBSD Net , s m X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 16:34:51 -0000 On Aug 8, 2013, at 10:27 AM, Peter Wemm wrote: > On Thu, Aug 8, 2013 at 12:04 AM, s m wrote: >> hello guys, >>=20 >> i have a question about ip addresses. i know my question is not = related to >> freebsd but i googled a lot and found nothing useful and don't know = where i >> should ask my question. >>=20 >> i want to know how can i calculate the number of ip addresses in a = range? >> for example if i have 192.0.0.1 192.100.255.254 with mask 8, how many = ip >> addresses are available in this range? is there any formula to = calculate >> the number of ip addresses for any range? >>=20 >> i'm confusing about it. please help me to clear my mind. >> thanks in advance, >=20 > My immediate reaction is.. is this a homework / classwork / = assignment? >=20 > Anyway, you can think of it by converting your start and end addresses > to an integer. Over simplified: >=20 > $ cat homework.c > main() > { > int start =3D (192 << 24) | (0 << 16) | (0 << 8) | 1; > int end =3D (192 << 24) | (100 << 16) | (255 << 8) | 254; > printf("start %d end %d range %d\n", start, end, (end - start) + 1); > } > $ ./homework > start -1073741823 end -1067122690 range 6619134 >=20 > The +1 is correcting for base zero. 192.0.0.1 - 192.0.0.2 is two > usable addresses. >=20 > I'm not sure what you want to do with the mask of 8. >=20 > You can also do it with ntohl(inet_addr("address")) as well and a > multitude of other ways. Hold on a second, why would you correct the base zero ? It can be a valid IP address. = https://labs.ripe.net/Members/stephane_bortzmeyer/all-ip-addresses-are-equ= al-dot-zero-addresses-are-less-equal From owner-freebsd-net@FreeBSD.ORG Fri Aug 9 19:20:25 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F039CCFA for ; Fri, 9 Aug 2013 19:20:25 +0000 (UTC) (envelope-from smb@cs.columbia.edu) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B10BA2C1A for ; Fri, 9 Aug 2013 19:20:25 +0000 (UTC) Received: from [10.9.0.138] (fireball.cs.columbia.edu [128.59.13.10]) (user=smb2132 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r79ImYql025193 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 9 Aug 2013 14:48:35 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: BPF_MISC+BPF_COP and BPF_COPX From: Steven Bellovin In-Reply-To: <5203535D.2040508@netbsd.org> Date: Fri, 9 Aug 2013 14:48:34 -0400 Content-Transfer-Encoding: 7bit Message-Id: <38CDC9BB-09C7-4241-8746-163BD15B80EC@cs.columbia.edu> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <5202693C.50608@netbsd.org> <20130807175548.1528014A21F@mail.netbsd.org> <5203535D.2040508@netbsd.org> To: darrenr@NetBSD.org X-Mailer: Apple Mail (2.1508) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: tech-net@NetBSD.org, Mindaugas Rasiukevicius , guy@alum.mit.edu, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 19:20:26 -0000 On Aug 8, 2013, at 4:14 AM, Darren Reed wrote: > > No. It's not about calling a function, it is about proving the BPF > program is correct and secure. > > BPF today is essentially assembly language operations that are all > easily tested and verified. There's a one-word summary: *assurance*. With the current design, it's easy to *know* what can happen. With a Turing-complete extension, it isn't. Assurance is often what separates actually secure systems from ones that are merely claimed to be secure. --Steve Bellovin, https://www.cs.columbia.edu/~smb From owner-freebsd-net@FreeBSD.ORG Fri Aug 9 20:34:47 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id ED10CDD3 for ; Fri, 9 Aug 2013 20:34:47 +0000 (UTC) (envelope-from rmind@netbsd.org) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D8CEF20DF for ; Fri, 9 Aug 2013 20:34:47 +0000 (UTC) Received: from ws (localhost [IPv6:::1]) by mail.netbsd.org (Postfix) with SMTP id 428A714A308; Fri, 9 Aug 2013 20:34:46 +0000 (UTC) Date: Fri, 9 Aug 2013 21:34:25 +0100 From: Mindaugas Rasiukevicius To: Steven Bellovin Subject: Re: BPF_MISC+BPF_COP and BPF_COPX In-Reply-To: <38CDC9BB-09C7-4241-8746-163BD15B80EC@cs.columbia.edu> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <5202693C.50608@netbsd.org> <20130807175548.1528014A21F@mail.netbsd.org> <5203535D.2040508@netbsd.org> <38CDC9BB-09C7-4241-8746-163BD15B80EC@cs.columbia.edu> X-Mailer: mail(1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20130809203446.428A714A308@mail.netbsd.org> Cc: tech-net@NetBSD.org, guy@alum.mit.edu, darrenr@NetBSD.org, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 20:34:48 -0000 Steven, Steven Bellovin wrote: > There's a one-word summary: *assurance*. With the current design, > it's easy to *know* what can happen. With a Turing-complete extension, > it isn't. It is still easy and the concept itself is very simple. I mentioned that this extension does not make byte-code Turing-complete and the rest is in your control. Darren ignored it. -- Mindaugas From owner-freebsd-net@FreeBSD.ORG Fri Aug 9 21:02:12 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0F9C3DFE for ; Fri, 9 Aug 2013 21:02:12 +0000 (UTC) (envelope-from tls@panix.com) Received: from l2mail1.panix.com (l2mail1.panix.com [166.84.1.75]) by mx1.freebsd.org (Postfix) with ESMTP id AED562286 for ; Fri, 9 Aug 2013 21:02:11 +0000 (UTC) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by l2mail1.panix.com (Postfix) with ESMTP id 772C7128 for ; Fri, 9 Aug 2013 16:44:43 -0400 (EDT) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mailbackend.panix.com (Postfix) with ESMTP id 4679428F6F; Fri, 9 Aug 2013 16:44:37 -0400 (EDT) Received: by panix5.panix.com (Postfix, from userid 415) id 28CAE242E2; Fri, 9 Aug 2013 16:44:37 -0400 (EDT) Date: Fri, 9 Aug 2013 16:44:37 -0400 From: Thor Lancelot Simon To: Mindaugas Rasiukevicius Subject: Re: BPF_MISC+BPF_COP and BPF_COPX Message-ID: <20130809204436.GA3261@panix.com> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <5202693C.50608@netbsd.org> <20130807175548.1528014A21F@mail.netbsd.org> <5203535D.2040508@netbsd.org> <38CDC9BB-09C7-4241-8746-163BD15B80EC@cs.columbia.edu> <20130809203446.428A714A308@mail.netbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130809203446.428A714A308@mail.netbsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: tech-net@NetBSD.org, freebsd-net@freebsd.org, guy@alum.mit.edu, darrenr@NetBSD.org, Steven Bellovin X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 21:02:12 -0000 On Fri, Aug 09, 2013 at 09:34:25PM +0100, Mindaugas Rasiukevicius wrote: > Steven, > > Steven Bellovin wrote: > > There's a one-word summary: *assurance*. With the current design, > > it's easy to *know* what can happen. With a Turing-complete extension, > > it isn't. > > It is still easy and the concept itself is very simple. I mentioned that > this extension does not make byte-code Turing-complete and the rest is in > your control. Darren ignored it. Yes, but since the extension makes the program no longer consist solely of bytecode, it tends to give the impression that the program may now be, in total, in a Turing-complete language. It blurs the boundary between the program and its interpreter, by allowing the bytecode to directly call into the interpreter. Or am I missing something? I think what you want to do may be a good idea, in the end, but I do think it calls for what others are requesting: a real problem statement and an explanation of why the proposed solution is safer than it would at first appear. Thor From owner-freebsd-net@FreeBSD.ORG Fri Aug 9 21:05:38 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AED036B for ; Fri, 9 Aug 2013 21:05:38 +0000 (UTC) (envelope-from mouse@Chip.Rodents-Montreal.ORG) Received: from Chip.Rodents-Montreal.ORG (Chip.Rodents-Montreal.ORG [216.46.0.66]) by mx1.freebsd.org (Postfix) with ESMTP id 5533722D5 for ; Fri, 9 Aug 2013 21:05:38 +0000 (UTC) Received: (from mouse@localhost) by Chip.Rodents-Montreal.ORG (8.8.8/8.8.8) id RAA26682; Fri, 9 Aug 2013 17:01:23 -0400 (EDT) Date: Fri, 9 Aug 2013 17:01:23 -0400 (EDT) From: Mouse Message-Id: <201308092101.RAA26682@Chip.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Fri, 9 Aug 2013 16:55:10 -0400 (EDT) To: tech-net@NetBSD.org Subject: Re: BPF_MISC+BPF_COP and BPF_COPX In-Reply-To: <20130809204436.GA3261@panix.com> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <5202693C.50608@netbsd.org> <20130807175548.1528014A21F@mail.netbsd.org> <5203535D.2040508@netbsd.org> <38CDC9BB-09C7-4241-8746-163BD15B80EC@cs.columbia.edu> <20130809203446.428A714A308@mail.netbsd.org> <20130809204436.GA3261@panix.com> Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 21:05:38 -0000 > Yes, but since the extension makes the program no longer consist > solely of bytecode, it tends to give the impression that the program > may now be, in total, in a Turing-complete language. It blurs the > boundary between the program and its interpreter, by allowing the > bytecode to directly call into the interpreter. Like pretty much any bytecode, BPF bytecode is _nothing but_ direct calls into the interpreter. Except for psychological effects, this whole modification is nothing but reserving a particular range of bytecodes for per-(kernel-)user-of-bpf custom uses. Mind you, psychological effects can be important. But I think the biggest psychological effect here is the one that is causing most of the trouble: the way this is named and was described make it sound as though it is more general, and less safe, than it actually is. It bothered me too at first, but when it was clarified that a given COP function is not automatically available to every BPF program in the system just because it's available to one, I've been unable to come up with a reason to dislike this that I can actually defend to myself. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From owner-freebsd-net@FreeBSD.ORG Fri Aug 9 21:25:31 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DEC7FA54 for ; Fri, 9 Aug 2013 21:25:31 +0000 (UTC) (envelope-from rmind@netbsd.org) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C838A23C9 for ; Fri, 9 Aug 2013 21:25:31 +0000 (UTC) Received: from ws (localhost [IPv6:::1]) by mail.netbsd.org (Postfix) with SMTP id 1BF5F14A33B; Fri, 9 Aug 2013 21:25:29 +0000 (UTC) Date: Fri, 9 Aug 2013 22:25:09 +0100 From: Mindaugas Rasiukevicius To: Thor Lancelot Simon Subject: Re: BPF_MISC+BPF_COP and BPF_COPX In-Reply-To: <20130809204436.GA3261@panix.com> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <5202693C.50608@netbsd.org> <20130807175548.1528014A21F@mail.netbsd.org> <5203535D.2040508@netbsd.org> <38CDC9BB-09C7-4241-8746-163BD15B80EC@cs.columbia.edu> <20130809203446.428A714A308@mail.netbsd.org> <20130809204436.GA3261@panix.com> X-Mailer: mail(1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20130809212530.1BF5F14A33B@mail.netbsd.org> Cc: tech-net@NetBSD.org, freebsd-net@freebsd.org, guy@alum.mit.edu, darrenr@NetBSD.org, Steven Bellovin X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 21:25:31 -0000 Thor Lancelot Simon wrote: > On Fri, Aug 09, 2013 at 09:34:25PM +0100, Mindaugas Rasiukevicius wrote: > > Steven, > > > > Steven Bellovin wrote: > > > There's a one-word summary: *assurance*. With the current design, > > > it's easy to *know* what can happen. With a Turing-complete > > > extension, it isn't. > > > > It is still easy and the concept itself is very simple. I mentioned > > that this extension does not make byte-code Turing-complete and the > > rest is in your control. Darren ignored it. > > Yes, but since the extension makes the program no longer consist solely > of bytecode, it tends to give the impression that the program may now > be, in total, in a Turing-complete language. It blurs the boundary > between the program and its interpreter, by allowing the bytecode to > directly call into the interpreter. Or am I missing something? I think "impression" is the right word here. :) The extension i.e. the coprocessor cannot change the flow of your program. It can inspect the packet in a read-only manner and return couple 32-bit numbers. Nothing really more, unless you are abusing the provided interface and writing some crazy coprocessor functions. However, you can as well write crazy code in tcp_input(). I think we have enough common sense to not do that. > I think what you want to do may be a good idea, in the end, but I do > think it calls for what others are requesting: a real problem statement > and an explanation of why the proposed solution is safer than it would > at first appear. The problem is simple: I want a generic mechanism to offload more complex packet inspection operations, e.g. lookup IP address in some container or walk IPv6 headers and return some offsets. There is no reason why we need a separate instruction for each operation, it can (and I argue that it should) be generic. -- Mindaugas From owner-freebsd-net@FreeBSD.ORG Fri Aug 9 21:32:15 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D9085E7 for ; Fri, 9 Aug 2013 21:32:15 +0000 (UTC) (envelope-from matt@3am-software.com) Received: from panix.3am-software.com (panix.3am-software.com [166.84.6.62]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 86275245B for ; Fri, 9 Aug 2013 21:32:15 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by panix.3am-software.com (Postfix) with ESMTP id 9035D278405; Fri, 9 Aug 2013 17:39:21 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: BPF_MISC+BPF_COP and BPF_COPX From: Matt Thomas In-Reply-To: <20130809204436.GA3261@panix.com> Date: Fri, 9 Aug 2013 14:23:04 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <20130804191310.2FFBB14A152@mail.netbsd.org> <5202693C.50608@netbsd.org> <20130807175548.1528014A21F@mail.netbsd.org> <5203535D.2040508@netbsd.org> <38CDC9BB-09C7-4241-8746-163BD15B80EC@cs.columbia.edu> <20130809203446.428A714A308@mail.netbsd.org> <20130809204436.GA3261@panix.com> To: Thor Lancelot Simon X-Mailer: Apple Mail (2.1508) Cc: tech-net@NetBSD.org, guy@alum.mit.edu, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 21:32:15 -0000 On Aug 9, 2013, at 1:44 PM, Thor Lancelot Simon wrote: > On Fri, Aug 09, 2013 at 09:34:25PM +0100, Mindaugas Rasiukevicius wrote: >> Steven, >> >> Steven Bellovin wrote: >>> There's a one-word summary: *assurance*. With the current design, >>> it's easy to *know* what can happen. With a Turing-complete extension, >>> it isn't. >> >> It is still easy and the concept itself is very simple. I mentioned that >> this extension does not make byte-code Turing-complete and the rest is in >> your control. Darren ignored it. > > Yes, but since the extension makes the program no longer consist solely > of bytecode, it tends to give the impression that the program may now > be, in total, in a Turing-complete language. It blurs the boundary > between the program and its interpreter, by allowing the bytecode to > directly call into the interpreter. Or am I missing something? You already have to trust the interpreter, you are now extending that trust to who invoked the interpreter. One aspect of all this is that by allowing the invoker to setup the initial register set used by the BPF program and then having access to it after it returns, you can have BPF do more sophisticated things than just returning a scalar. The possibility of the COP/COPX functions doing bad things is over wrought. It makes the assumption of avoiding BPF and then coding everything is safer than using BPF and COP/COPX functions. From owner-freebsd-net@FreeBSD.ORG Fri Aug 9 22:44:53 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A65B1E73 for ; Fri, 9 Aug 2013 22:44:53 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5DA542729 for ; Fri, 9 Aug 2013 22:44:53 +0000 (UTC) Received: by mail-vc0-f180.google.com with SMTP id gf11so1443232vcb.25 for ; Fri, 09 Aug 2013 15:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qu3G/DyEl43WM+FIo79IrRDvdEyqxWtK7beZ2kavskM=; b=MVUv8eE7/6lnSiVuQVisLL8+x74dzFbmB8M1+sMbFLuNVgQOcNWqTkpwg5eJQyP39L 2Ol98Aq/JIofBNb17C5QoRi0dtADAbiIEV+WoHZ2pB0JIyK0gnS9dsaOuu2CH5eK/cMM 4454IohQkfV/1H7NX6WrAa+O9rnrCeohV0UPA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qu3G/DyEl43WM+FIo79IrRDvdEyqxWtK7beZ2kavskM=; b=f0pc0uNxBOJaF0JVeS8YMGnHvpWw2fa5qs7wSFEPZTqN30VVzPfHh8PmEKi3RR6bXb wZiLFxpAippk5SAD1N624rZiUJjVH4eN14l5Rh/lIueKdVHrvO8YqCqDQg1Xwe8OjiRH XllAoJSI4sUNDirFMRTTDS5Fc/TomsMuuh7qqgUS850+SG3Jd2evUXEnPgiXOcsWCD8d m/LWoWmcmXfTqbcOI/WSgis+ghjf3MjJE8xdRRd81twVFH7xlQYYj4l5H05SD1+JrKmV FHzus01B27SIQEaX8mmnyaZWSUkupG+rd0MaF/0JUE9xPV2QXvh+34qwBUQZUTqs95ud BsNw== X-Gm-Message-State: ALoCoQmrm5M01tjC2sKQDjQqpZECY4MrOUKhgds9oJUOWE9I4qi2XJEgcJ3k3Tqvs1tEtwwPfXcA MIME-Version: 1.0 X-Received: by 10.52.30.18 with SMTP id o18mr1398019vdh.114.1376088292161; Fri, 09 Aug 2013 15:44:52 -0700 (PDT) Received: by 10.220.167.74 with HTTP; Fri, 9 Aug 2013 15:44:52 -0700 (PDT) In-Reply-To: <8B53C542-5CC3-45E6-AA62-B9F52A735EE5@my.gd> References: <8B53C542-5CC3-45E6-AA62-B9F52A735EE5@my.gd> Date: Fri, 9 Aug 2013 15:44:52 -0700 Message-ID: Subject: Re: how calculate the number of ip addresses in a range? From: Peter Wemm To: Fleuriot Damien Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net , s m X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 22:44:53 -0000 On Fri, Aug 9, 2013 at 9:34 AM, Fleuriot Damien wrote: > > On Aug 8, 2013, at 10:27 AM, Peter Wemm wrote: > >> On Thu, Aug 8, 2013 at 12:04 AM, s m wrote: >>> hello guys, >>> >>> i have a question about ip addresses. i know my question is not related to >>> freebsd but i googled a lot and found nothing useful and don't know where i >>> should ask my question. >>> >>> i want to know how can i calculate the number of ip addresses in a range? >>> for example if i have 192.0.0.1 192.100.255.254 with mask 8, how many ip >>> addresses are available in this range? is there any formula to calculate >>> the number of ip addresses for any range? >>> >>> i'm confusing about it. please help me to clear my mind. >>> thanks in advance, >> >> My immediate reaction is.. is this a homework / classwork / assignment? >> >> Anyway, you can think of it by converting your start and end addresses >> to an integer. Over simplified: >> >> $ cat homework.c >> main() >> { >> int start = (192 << 24) | (0 << 16) | (0 << 8) | 1; >> int end = (192 << 24) | (100 << 16) | (255 << 8) | 254; >> printf("start %d end %d range %d\n", start, end, (end - start) + 1); >> } >> $ ./homework >> start -1073741823 end -1067122690 range 6619134 >> >> The +1 is correcting for base zero. 192.0.0.1 - 192.0.0.2 is two >> usable addresses. >> >> I'm not sure what you want to do with the mask of 8. >> >> You can also do it with ntohl(inet_addr("address")) as well and a >> multitude of other ways. > > > Hold on a second, why would you correct the base zero ? > It can be a valid IP address. There is one usable address in a range of 10.0.0.1 - 10.0.0.1. Converting to an integer and subtracting would be zero. Hence +1. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV UTF-8: for when a ' just won\342\200\231t do. ZFS must be the bacon of file systems. "everything's better with ZFS" From owner-freebsd-net@FreeBSD.ORG Fri Aug 9 23:07:13 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 03707681 for ; Fri, 9 Aug 2013 23:07:13 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-qe0-x232.google.com (mail-qe0-x232.google.com [IPv6:2607:f8b0:400d:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B56FE2860 for ; Fri, 9 Aug 2013 23:07:12 +0000 (UTC) Received: by mail-qe0-f50.google.com with SMTP id q19so2639248qeb.37 for ; Fri, 09 Aug 2013 16:07:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FWzFTnMVXDSovQOoeqDorPCAqVWRDc+x3PhqckI/Nm4=; b=X7c7BdFx2P1tvkDPy8LHvDoO5UZDGU4rhgcWb0HXEdsJG4jWFV+22bOREz0+RLDgUH vXD0CdZZ24ruCEaXmHMnFOjRXyA2bQxfzT9LGb+ARWQGIykUdNZqfoNxgAXIhCVvlvIi iBCJhd8Hm3Sbx2PQR/B8S4oCVYdUyZ7haDj7MP3kFUEdr983sJOm5bIq13WfGQ4XP3+u y/PfiEUEdzPYJt9AxheBpHLQmX/dDzTOu1a+4e/hsuMFZAQmekDsRGsSYPXwkVSy9v9B pU9yVu2TKJrQyXiPGhyRw+KF/7Tu9FIkMYvZ7CF7x5Fp504cauYmQ2HNByzBq0hQrwo/ CDvQ== MIME-Version: 1.0 X-Received: by 10.224.3.197 with SMTP id 5mr13538443qao.25.1376089631701; Fri, 09 Aug 2013 16:07:11 -0700 (PDT) Received: by 10.224.5.195 with HTTP; Fri, 9 Aug 2013 16:07:11 -0700 (PDT) In-Reply-To: References: <8B53C542-5CC3-45E6-AA62-B9F52A735EE5@my.gd> Date: Sat, 10 Aug 2013 02:07:11 +0300 Message-ID: Subject: Re: how calculate the number of ip addresses in a range? From: Kimmo Paasiala To: Peter Wemm Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Net , Fleuriot Damien , s m X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 23:07:13 -0000 On Sat, Aug 10, 2013 at 1:44 AM, Peter Wemm wrote: > On Fri, Aug 9, 2013 at 9:34 AM, Fleuriot Damien wrote: >> >> On Aug 8, 2013, at 10:27 AM, Peter Wemm wrote: >> >>> On Thu, Aug 8, 2013 at 12:04 AM, s m wrote: >>>> hello guys, >>>> >>>> i have a question about ip addresses. i know my question is not related to >>>> freebsd but i googled a lot and found nothing useful and don't know where i >>>> should ask my question. >>>> >>>> i want to know how can i calculate the number of ip addresses in a range? >>>> for example if i have 192.0.0.1 192.100.255.254 with mask 8, how many ip >>>> addresses are available in this range? is there any formula to calculate >>>> the number of ip addresses for any range? >>>> >>>> i'm confusing about it. please help me to clear my mind. >>>> thanks in advance, >>> >>> My immediate reaction is.. is this a homework / classwork / assignment? >>> >>> Anyway, you can think of it by converting your start and end addresses >>> to an integer. Over simplified: >>> >>> $ cat homework.c >>> main() >>> { >>> int start = (192 << 24) | (0 << 16) | (0 << 8) | 1; >>> int end = (192 << 24) | (100 << 16) | (255 << 8) | 254; >>> printf("start %d end %d range %d\n", start, end, (end - start) + 1); >>> } >>> $ ./homework >>> start -1073741823 end -1067122690 range 6619134 >>> >>> The +1 is correcting for base zero. 192.0.0.1 - 192.0.0.2 is two >>> usable addresses. >>> >>> I'm not sure what you want to do with the mask of 8. >>> >>> You can also do it with ntohl(inet_addr("address")) as well and a >>> multitude of other ways. >> >> >> Hold on a second, why would you correct the base zero ? >> It can be a valid IP address. > > There is one usable address in a range of 10.0.0.1 - 10.0.0.1. > Converting to an integer and subtracting would be zero. Hence +1. > > -- To elaborate on this, for every subnet regardless of the address/mask combination there are two unusable addresses: The first address aka the "network address" and the last address aka the "broadcast address". There may be usable address in between the two that end in one of more zeros but those addresses are still valid. Some operating systems got this horribly wrong and marked any address ending with a single zero as invalid, windows 2000 was one of them. -Kimmo From owner-freebsd-net@FreeBSD.ORG Fri Aug 9 23:13:19 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6671D84B for ; Fri, 9 Aug 2013 23:13:19 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 21C5A28BE for ; Fri, 9 Aug 2013 23:13:19 +0000 (UTC) Received: by mail-qc0-f171.google.com with SMTP id o11so498629qcv.2 for ; Fri, 09 Aug 2013 16:13:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=T8ff5lLF1ZdMAGq4zwEyhvZgVa48tW4jq+Ep4fgJ2eE=; b=lZ9YS8LWPkvrZHm/6MifLh5MXTuUMDdRQnDb0kg+xX3lM6432GWKCQeI84Ek/EN7ah QqtqP5LUhANwmIAiZ9dP/tZF699hvLBFfBujee2A1udYs159MiNs8Ar1P37skAm2wTXZ pQDdb6jRl+igBRVBrb44mIcu5qxrTUKVywlLPQlpQ710zj+4DRKUPOVgX3VgZPlKAdBa PBJrymeyHcl2erLQouE++GPZ9+Q5otkq7lUukdduk7LjA2CxlcIUvT7ivLHbGIOIdjx4 VTfqh5bexczP8BU3gv00p1o/E96CahBXD3o2GolsPZBYByBuljrmMbosv/XD4xqSFXK+ 4FFg== MIME-Version: 1.0 X-Received: by 10.49.127.196 with SMTP id ni4mr3081865qeb.5.1376089998102; Fri, 09 Aug 2013 16:13:18 -0700 (PDT) Received: by 10.224.5.195 with HTTP; Fri, 9 Aug 2013 16:13:18 -0700 (PDT) In-Reply-To: References: <8B53C542-5CC3-45E6-AA62-B9F52A735EE5@my.gd> Date: Sat, 10 Aug 2013 02:13:18 +0300 Message-ID: Subject: Re: how calculate the number of ip addresses in a range? From: Kimmo Paasiala To: Peter Wemm Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Net , Fleuriot Damien , s m X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 23:13:19 -0000 On Sat, Aug 10, 2013 at 2:07 AM, Kimmo Paasiala wrote: > On Sat, Aug 10, 2013 at 1:44 AM, Peter Wemm wrote: >> On Fri, Aug 9, 2013 at 9:34 AM, Fleuriot Damien wrote: >>> >>> On Aug 8, 2013, at 10:27 AM, Peter Wemm wrote: >>> >>>> On Thu, Aug 8, 2013 at 12:04 AM, s m wrote: >>>>> hello guys, >>>>> >>>>> i have a question about ip addresses. i know my question is not related to >>>>> freebsd but i googled a lot and found nothing useful and don't know where i >>>>> should ask my question. >>>>> >>>>> i want to know how can i calculate the number of ip addresses in a range? >>>>> for example if i have 192.0.0.1 192.100.255.254 with mask 8, how many ip >>>>> addresses are available in this range? is there any formula to calculate >>>>> the number of ip addresses for any range? >>>>> >>>>> i'm confusing about it. please help me to clear my mind. >>>>> thanks in advance, >>>> >>>> My immediate reaction is.. is this a homework / classwork / assignment? >>>> >>>> Anyway, you can think of it by converting your start and end addresses >>>> to an integer. Over simplified: >>>> >>>> $ cat homework.c >>>> main() >>>> { >>>> int start = (192 << 24) | (0 << 16) | (0 << 8) | 1; >>>> int end = (192 << 24) | (100 << 16) | (255 << 8) | 254; >>>> printf("start %d end %d range %d\n", start, end, (end - start) + 1); >>>> } >>>> $ ./homework >>>> start -1073741823 end -1067122690 range 6619134 >>>> >>>> The +1 is correcting for base zero. 192.0.0.1 - 192.0.0.2 is two >>>> usable addresses. >>>> >>>> I'm not sure what you want to do with the mask of 8. >>>> >>>> You can also do it with ntohl(inet_addr("address")) as well and a >>>> multitude of other ways. >>> >>> >>> Hold on a second, why would you correct the base zero ? >>> It can be a valid IP address. >> >> There is one usable address in a range of 10.0.0.1 - 10.0.0.1. >> Converting to an integer and subtracting would be zero. Hence +1. >> >> -- > > To elaborate on this, for every subnet regardless of the address/mask > combination there are two unusable addresses: The first address aka > the "network address" and the last address aka the "broadcast > address". There may be usable address in between the two that end in > one of more zeros but those addresses are still valid. Some operating > systems got this horribly wrong and marked any address ending with a > single zero as invalid, windows 2000 was one of them. > > -Kimmo Of course I should have mentioned that there are special cases to address/mask combinations, /31 and /32 masks have to be treated specially or there are no usable addresses at all. -Kimmo From owner-freebsd-net@FreeBSD.ORG Fri Aug 9 23:17:06 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id ED572A4A for ; Fri, 9 Aug 2013 23:17:06 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A322228E6 for ; Fri, 9 Aug 2013 23:17:06 +0000 (UTC) Received: by mail-vb0-f50.google.com with SMTP id x14so4548856vbb.9 for ; Fri, 09 Aug 2013 16:17:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=W4dxAWQEgK2jILIbLfFVymdEY4a8zdUICCSrEj9UAXY=; b=hYiMPiatUr4RDEE4wGg/mMc2JbPLP3zBZaosAH9oPa8qbN9Q0u6Jm6DIk9Ou3q45sy 3ys1u0o4/EKEjhJIGIZDsDgGtRf5JjihdhAbbU4UGBpzdPk8iGYch1mbnic6hZ+XXJXu oOYtotBZpvYG224EMsv6xZgjbRHecfvBo4MF0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=W4dxAWQEgK2jILIbLfFVymdEY4a8zdUICCSrEj9UAXY=; b=P91yN/HRTrRFUro4QWjwuUtYw+iwuGZh5419wA09cBPnUUOcfuNQzQzztdkq99eAMB JJjZd4cna/V2Mh8wORarV5a+ei3FWzKA1Jw3APLZ7Tf7DSRMGIw64/nGNdzdt09aGxg3 rzvCnLPPgZxzkO6daq3csVEWgUD9VkZQ6oV/I+HUtMSEBoEZW4Tcv5PFa6RqntKP8ble tC/JK2auwg+jKPXMiRW4wIZVkYcQfjItavkqQh1aE2FeraBCWcZ/3OaRwwcRFE3o8wBY trLNN36nY2mNgIxUJSlv3b9tPv9Rb3xWlK+aw99uITS9djTHEXaHOml6Ksc9CEnmqgCd halQ== X-Gm-Message-State: ALoCoQn3JMKCguE751lzi1ddyo3ZbXnPuRnEsA5jl2ya0hOSh14VuQ7lCrQrTCYzh0cELdG7WmOn MIME-Version: 1.0 X-Received: by 10.52.30.18 with SMTP id o18mr1439025vdh.114.1376090225724; Fri, 09 Aug 2013 16:17:05 -0700 (PDT) Received: by 10.220.167.74 with HTTP; Fri, 9 Aug 2013 16:17:05 -0700 (PDT) In-Reply-To: References: <8B53C542-5CC3-45E6-AA62-B9F52A735EE5@my.gd> Date: Fri, 9 Aug 2013 16:17:05 -0700 Message-ID: Subject: Re: how calculate the number of ip addresses in a range? From: Peter Wemm To: Kimmo Paasiala Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net , Fleuriot Damien , s m X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 23:17:07 -0000 On Fri, Aug 9, 2013 at 4:07 PM, Kimmo Paasiala wrote: > On Sat, Aug 10, 2013 at 1:44 AM, Peter Wemm wrote: >> On Fri, Aug 9, 2013 at 9:34 AM, Fleuriot Damien wrote: >>> >>> On Aug 8, 2013, at 10:27 AM, Peter Wemm wrote: >>> >>>> On Thu, Aug 8, 2013 at 12:04 AM, s m wrote: >>>>> hello guys, >>>>> >>>>> i have a question about ip addresses. i know my question is not related to >>>>> freebsd but i googled a lot and found nothing useful and don't know where i >>>>> should ask my question. >>>>> >>>>> i want to know how can i calculate the number of ip addresses in a range? >>>>> for example if i have 192.0.0.1 192.100.255.254 with mask 8, how many ip >>>>> addresses are available in this range? is there any formula to calculate >>>>> the number of ip addresses for any range? >>>>> >>>>> i'm confusing about it. please help me to clear my mind. >>>>> thanks in advance, >>>> >>>> My immediate reaction is.. is this a homework / classwork / assignment? >>>> >>>> Anyway, you can think of it by converting your start and end addresses >>>> to an integer. Over simplified: >>>> >>>> $ cat homework.c >>>> main() >>>> { >>>> int start = (192 << 24) | (0 << 16) | (0 << 8) | 1; >>>> int end = (192 << 24) | (100 << 16) | (255 << 8) | 254; >>>> printf("start %d end %d range %d\n", start, end, (end - start) + 1); >>>> } >>>> $ ./homework >>>> start -1073741823 end -1067122690 range 6619134 >>>> >>>> The +1 is correcting for base zero. 192.0.0.1 - 192.0.0.2 is two >>>> usable addresses. >>>> >>>> I'm not sure what you want to do with the mask of 8. >>>> >>>> You can also do it with ntohl(inet_addr("address")) as well and a >>>> multitude of other ways. >>> >>> >>> Hold on a second, why would you correct the base zero ? >>> It can be a valid IP address. >> >> There is one usable address in a range of 10.0.0.1 - 10.0.0.1. >> Converting to an integer and subtracting would be zero. Hence +1. >> >> -- > > To elaborate on this, for every subnet regardless of the address/mask > combination there are two unusable addresses: The first address aka > the "network address" and the last address aka the "broadcast > address". There may be usable address in between the two that end in > one of more zeros but those addresses are still valid. Some operating > systems got this horribly wrong and marked any address ending with a > single zero as invalid, windows 2000 was one of them. > > -Kimmo If we go back to the orignal question: "if i have 192.0.0.1 192.100.255.254 how many ip addresses are available in this range?" They're all in the same 192.0.0.0/8. Broadcast or sink addresses don't factor into it. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV UTF-8: for when a ' just won\342\200\231t do. ZFS must be the bacon of file systems. "everything's better with ZFS" From owner-freebsd-net@FreeBSD.ORG Sat Aug 10 00:52:43 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F313DD07 for ; Sat, 10 Aug 2013 00:52:42 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8087F2DF4 for ; Sat, 10 Aug 2013 00:52:42 +0000 (UTC) Received: by mail-we0-f178.google.com with SMTP id u57so4086604wes.9 for ; Fri, 09 Aug 2013 17:52:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=240XYwN6Y8EFJUhXq7QRyZeTDis2pXUdDWiCNFZRd1c=; b=iICuuxhZGDm2Amm9IJr+DdShzgDkjew0u1rsbCoxfzU9UDaZn2sHBwlZs6fQ8jBR+1 7ISo4Z3oHxcmBCGGEAOfENL7Qlv1/D3ISBZVWF2pmPGfrbhi82x14r68a5AsLflbSlrg 5rzWv5Q5hJhXUks3ZncchGeqSMq07Ky1Dbwt93ybWB8XRO74HedKO2fBQRX2DAFz6fBt 7D+2EWg1i0+J9ycM0Kb0ovZ/POg5UAxOam6SuM1Ndv9V5EnDaKwnvCZZ+1LU/YaL9JGv EXsvDaoKrWRugWGSZgdsl5r7/O7a4yXK4xjgy+dvVHvGBo+91cAYQ9hZDbP8KhEgpVDM qJiQ== X-Gm-Message-State: ALoCoQmiiMfpc9ZaEnGNaKpjsAs2uBFYPuKHPmocf9ADxF7g/ucEXgg7B0oH1+qDHhyifv31W8WG X-Received: by 10.194.172.228 with SMTP id bf4mr7405544wjc.36.1376095953781; Fri, 09 Aug 2013 17:52:33 -0700 (PDT) Received: from [10.51.25.177] (86.20.90.92.rev.sfr.net. [92.90.20.86]) by mx.google.com with ESMTPSA id mb7sm5238100wic.10.2013.08.09.17.52.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 Aug 2013 17:52:32 -0700 (PDT) References: <8B53C542-5CC3-45E6-AA62-B9F52A735EE5@my.gd> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B144) From: Damien Fleuriot Subject: Re: how calculate the number of ip addresses in a range? Date: Sat, 10 Aug 2013 02:50:53 +0200 To: Kimmo Paasiala Cc: FreeBSD Net , s m , Peter Wemm X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 00:52:43 -0000 On 10 Aug 2013, at 01:13, Kimmo Paasiala wrote: > On Sat, Aug 10, 2013 at 2:07 AM, Kimmo Paasiala wrote= : >> On Sat, Aug 10, 2013 at 1:44 AM, Peter Wemm wrote: >>> On Fri, Aug 9, 2013 at 9:34 AM, Fleuriot Damien wrote: >>>>=20 >>>> On Aug 8, 2013, at 10:27 AM, Peter Wemm wrote: >>>>=20 >>>>> On Thu, Aug 8, 2013 at 12:04 AM, s m wrote: >>>>>> hello guys, >>>>>>=20 >>>>>> i have a question about ip addresses. i know my question is not relat= ed to >>>>>> freebsd but i googled a lot and found nothing useful and don't know w= here i >>>>>> should ask my question. >>>>>>=20 >>>>>> i want to know how can i calculate the number of ip addresses in a ra= nge? >>>>>> for example if i have 192.0.0.1 192.100.255.254 with mask 8, how many= ip >>>>>> addresses are available in this range? is there any formula to calcul= ate >>>>>> the number of ip addresses for any range? >>>>>>=20 >>>>>> i'm confusing about it. please help me to clear my mind. >>>>>> thanks in advance, >>>>>=20 >>>>> My immediate reaction is.. is this a homework / classwork / assignment= ? >>>>>=20 >>>>> Anyway, you can think of it by converting your start and end addresses= >>>>> to an integer. Over simplified: >>>>>=20 >>>>> $ cat homework.c >>>>> main() >>>>> { >>>>> int start =3D (192 << 24) | (0 << 16) | (0 << 8) | 1; >>>>> int end =3D (192 << 24) | (100 << 16) | (255 << 8) | 254; >>>>> printf("start %d end %d range %d\n", start, end, (end - start) + 1); >>>>> } >>>>> $ ./homework >>>>> start -1073741823 end -1067122690 range 6619134 >>>>>=20 >>>>> The +1 is correcting for base zero. 192.0.0.1 - 192.0.0.2 is two >>>>> usable addresses. >>>>>=20 >>>>> I'm not sure what you want to do with the mask of 8. >>>>>=20 >>>>> You can also do it with ntohl(inet_addr("address")) as well and a >>>>> multitude of other ways. >>>>=20 >>>>=20 >>>> Hold on a second, why would you correct the base zero ? >>>> It can be a valid IP address. >>>=20 >>> There is one usable address in a range of 10.0.0.1 - 10.0.0.1. >>> Converting to an integer and subtracting would be zero. Hence +1. >>>=20 >>> -- >>=20 >> To elaborate on this, for every subnet regardless of the address/mask >> combination there are two unusable addresses: The first address aka >> the "network address" and the last address aka the "broadcast >> address". There may be usable address in between the two that end in >> one of more zeros but those addresses are still valid. Some operating >> systems got this horribly wrong and marked any address ending with a >> single zero as invalid, windows 2000 was one of them. >>=20 >> -Kimmo >=20 > Of course I should have mentioned that there are special cases to > address/mask combinations, /31 and /32 masks have to be treated > specially or there are no usable addresses at all. >=20 > -Kimmo Fully agree, /31 and /32 are special cases indeed.= From owner-freebsd-net@FreeBSD.ORG Sat Aug 10 00:54:37 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 65800EDF for ; Sat, 10 Aug 2013 00:54:37 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E6D052E0D for ; Sat, 10 Aug 2013 00:54:36 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id p61so4085722wes.11 for ; Fri, 09 Aug 2013 17:54:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=8P3gfO7BlPaftX04hENdPoBPEbiFf1xhMc9fdmMFoic=; b=iiEKYdiB/10lf7aryWSlg8MumK/UdLg8cFeCmxG0yXavs2a0Du7n7FVa2rs5AfYbtb fzmqadmXdUAuK1bo7mJT9MfKOKhV52H4jtkTXntlLCtEKeyA0PKpeH633fSyQu5Cd52M +am2mdrNODTpNDJ4XB0vfB3kjxLCwG3c8Y2VbnhqV6Vw7rAtn/DHAcoNE5Nu3FRoTpGj xSkOmri89/Iw+UK3NMYYojnUFDDFGlhSAbWLi+vWEeGnArVmcfw0OMCRoPXfPhT1gLmO pqfSCBcUNv6jfn9Bit3/Y2GIlrFstxJ42v58vJaEnHjdE83Y2th+Kbpl5QiSZNHe4iYH z8/g== X-Gm-Message-State: ALoCoQkcOJ9I8aVM7T+2AuiXhpTk/XET5jr87mGoCqEFie6Y7PJ2Z/RKsc6iG3K1nEd9nTWcgRle X-Received: by 10.194.9.229 with SMTP id d5mr1689817wjb.66.1376096075133; Fri, 09 Aug 2013 17:54:35 -0700 (PDT) Received: from [10.51.25.177] (86.20.90.92.rev.sfr.net. [92.90.20.86]) by mx.google.com with ESMTPSA id v9sm5243325wiw.8.2013.08.09.17.54.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 Aug 2013 17:54:34 -0700 (PDT) References: <8B53C542-5CC3-45E6-AA62-B9F52A735EE5@my.gd> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B144) From: Damien Fleuriot Subject: Re: how calculate the number of ip addresses in a range? Date: Sat, 10 Aug 2013 02:52:55 +0200 To: Peter Wemm Cc: Kimmo Paasiala , s m , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 00:54:37 -0000 On 10 Aug 2013, at 01:17, Peter Wemm wrote: > On Fri, Aug 9, 2013 at 4:07 PM, Kimmo Paasiala wrote:= >> On Sat, Aug 10, 2013 at 1:44 AM, Peter Wemm wrote: >>> On Fri, Aug 9, 2013 at 9:34 AM, Fleuriot Damien wrote: >>>>=20 >>>> On Aug 8, 2013, at 10:27 AM, Peter Wemm wrote: >>>>=20 >>>>> On Thu, Aug 8, 2013 at 12:04 AM, s m wrote: >>>>>> hello guys, >>>>>>=20 >>>>>> i have a question about ip addresses. i know my question is not relat= ed to >>>>>> freebsd but i googled a lot and found nothing useful and don't know w= here i >>>>>> should ask my question. >>>>>>=20 >>>>>> i want to know how can i calculate the number of ip addresses in a ra= nge? >>>>>> for example if i have 192.0.0.1 192.100.255.254 with mask 8, how many= ip >>>>>> addresses are available in this range? is there any formula to calcul= ate >>>>>> the number of ip addresses for any range? >>>>>>=20 >>>>>> i'm confusing about it. please help me to clear my mind. >>>>>> thanks in advance, >>>>>=20 >>>>> My immediate reaction is.. is this a homework / classwork / assignment= ? >>>>>=20 >>>>> Anyway, you can think of it by converting your start and end addresses= >>>>> to an integer. Over simplified: >>>>>=20 >>>>> $ cat homework.c >>>>> main() >>>>> { >>>>> int start =3D (192 << 24) | (0 << 16) | (0 << 8) | 1; >>>>> int end =3D (192 << 24) | (100 << 16) | (255 << 8) | 254; >>>>> printf("start %d end %d range %d\n", start, end, (end - start) + 1); >>>>> } >>>>> $ ./homework >>>>> start -1073741823 end -1067122690 range 6619134 >>>>>=20 >>>>> The +1 is correcting for base zero. 192.0.0.1 - 192.0.0.2 is two >>>>> usable addresses. >>>>>=20 >>>>> I'm not sure what you want to do with the mask of 8. >>>>>=20 >>>>> You can also do it with ntohl(inet_addr("address")) as well and a >>>>> multitude of other ways. >>>>=20 >>>>=20 >>>> Hold on a second, why would you correct the base zero ? >>>> It can be a valid IP address. >>>=20 >>> There is one usable address in a range of 10.0.0.1 - 10.0.0.1. >>> Converting to an integer and subtracting would be zero. Hence +1. >>>=20 >>> -- >>=20 >> To elaborate on this, for every subnet regardless of the address/mask >> combination there are two unusable addresses: The first address aka >> the "network address" and the last address aka the "broadcast >> address". There may be usable address in between the two that end in >> one of more zeros but those addresses are still valid. Some operating >> systems got this horribly wrong and marked any address ending with a >> single zero as invalid, windows 2000 was one of them. >>=20 >> -Kimmo >=20 > If we go back to the orignal question: "if i have 192.0.0.1 > 192.100.255.254 how many ip addresses are available in this range?" > They're all in the same 192.0.0.0/8. Broadcast or sink addresses > don't factor into it. >=20 > --=20 > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJ= V > UTF-8: for when a ' just won\342\200\231t do. > ZFS must be the bacon of file systems. "everything's better wit= h ZFS" Peter, The original question is "how to calculate a range", nobody said it should b= e a /24, that was merely an example.= From owner-freebsd-net@FreeBSD.ORG Sat Aug 10 00:58:29 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 590E294 for ; Sat, 10 Aug 2013 00:58:29 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DB6F42E2A for ; Sat, 10 Aug 2013 00:58:28 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id l18so244748wgh.2 for ; Fri, 09 Aug 2013 17:58:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=HVvf0wctHCuKIPmN/a1rEsNY3LUXFBZZtjKcUCCAP5o=; b=QCw+Mlyj7tHdFD5VEX77Af1Wi8eypel6xuRbiBhNzhLguMvqKctiKkHDQ7N7thm0A0 zwdeXEH3t2oAk3GAeYNhOFlbC604QXKFP9M5vyhuTI5fvlmH5KSY1j2cs2OD8HtWQUtM BMxThe98U9bMBWePNZWb7wp51oRVqZgco90Ovi6RA7DsCkXlf2uLegRqcgzBC//LixaH AYqoE33cS15xWHLM0WwgiWCmwwR4WcvCRedrkhW2hDcOyl7p2fD+n9EA6ObWsDXJN092 PMQkp6CXauhGzkO7Ccls7u1cHIx0UrTwkPCQNhSFupKPHo0e4irXbX+K63RR1gsnmrsA 3y3Q== X-Gm-Message-State: ALoCoQmkC8Cloo1qfHX3r31Lrg+oEqzFQAcBnNyX4mVJBkp0Wdxq6EnGAvEyBhYiLpUQkYWf+x5x X-Received: by 10.180.182.67 with SMTP id ec3mr1588303wic.1.1376095885517; Fri, 09 Aug 2013 17:51:25 -0700 (PDT) Received: from [10.51.25.177] (86.20.90.92.rev.sfr.net. [92.90.20.86]) by mx.google.com with ESMTPSA id jf9sm5244977wic.5.2013.08.09.17.51.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 Aug 2013 17:51:24 -0700 (PDT) References: <8B53C542-5CC3-45E6-AA62-B9F52A735EE5@my.gd> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B144) From: Damien Fleuriot Subject: Re: how calculate the number of ip addresses in a range? Date: Sat, 10 Aug 2013 02:49:45 +0200 To: Kimmo Paasiala Cc: FreeBSD Net , s m , Peter Wemm X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 00:58:29 -0000 On 10 Aug 2013, at 01:07, Kimmo Paasiala wrote: > On Sat, Aug 10, 2013 at 1:44 AM, Peter Wemm wrote: >> On Fri, Aug 9, 2013 at 9:34 AM, Fleuriot Damien wrote: >>>=20 >>> On Aug 8, 2013, at 10:27 AM, Peter Wemm wrote: >>>=20 >>>> On Thu, Aug 8, 2013 at 12:04 AM, s m wrote: >>>>> hello guys, >>>>>=20 >>>>> i have a question about ip addresses. i know my question is not relate= d to >>>>> freebsd but i googled a lot and found nothing useful and don't know wh= ere i >>>>> should ask my question. >>>>>=20 >>>>> i want to know how can i calculate the number of ip addresses in a ran= ge? >>>>> for example if i have 192.0.0.1 192.100.255.254 with mask 8, how many i= p >>>>> addresses are available in this range? is there any formula to calcula= te >>>>> the number of ip addresses for any range? >>>>>=20 >>>>> i'm confusing about it. please help me to clear my mind. >>>>> thanks in advance, >>>>=20 >>>> My immediate reaction is.. is this a homework / classwork / assignment?= >>>>=20 >>>> Anyway, you can think of it by converting your start and end addresses >>>> to an integer. Over simplified: >>>>=20 >>>> $ cat homework.c >>>> main() >>>> { >>>> int start =3D (192 << 24) | (0 << 16) | (0 << 8) | 1; >>>> int end =3D (192 << 24) | (100 << 16) | (255 << 8) | 254; >>>> printf("start %d end %d range %d\n", start, end, (end - start) + 1); >>>> } >>>> $ ./homework >>>> start -1073741823 end -1067122690 range 6619134 >>>>=20 >>>> The +1 is correcting for base zero. 192.0.0.1 - 192.0.0.2 is two >>>> usable addresses. >>>>=20 >>>> I'm not sure what you want to do with the mask of 8. >>>>=20 >>>> You can also do it with ntohl(inet_addr("address")) as well and a >>>> multitude of other ways. >>>=20 >>>=20 >>> Hold on a second, why would you correct the base zero ? >>> It can be a valid IP address. >>=20 >> There is one usable address in a range of 10.0.0.1 - 10.0.0.1. >> Converting to an integer and subtracting would be zero. Hence +1. >>=20 >> -- >=20 > To elaborate on this, for every subnet regardless of the address/mask > combination there are two unusable addresses: The first address aka > the "network address" and the last address aka the "broadcast > address". There may be usable address in between the two that end in > one of more zeros but those addresses are still valid. Some operating > systems got this horribly wrong and marked any address ending with a > single zero as invalid, windows 2000 was one of them. >=20 > -Kimmo Kimmo, That is untrue regarding /31 netmasks where you theoretically have 2^1 -2 ad= dresses. With such a short netmask the only 2 addresses are usable.=