From owner-freebsd-hackers@freebsd.org Mon Apr 25 08:01:12 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7632AB1CED8 for ; Mon, 25 Apr 2016 08:01:12 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from rayleigh.systella.fr (newton-ipv6.systella.fr [IPv6:2001:7a8:a8ed:253::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "rayleigh.systella.fr", Issuer "rayleigh.systella.fr" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3CFC81814 for ; Mon, 25 Apr 2016 08:01:11 +0000 (UTC) (envelope-from joel.bertrand@systella.fr) Received: from [192.168.2.3] (schroedinger.eikeo.com [192.168.2.3]) (authenticated bits=0) by rayleigh.systella.fr (8.15.2/8.15.2/Debian-4) with ESMTPSA id u3P80r0M000455 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 25 Apr 2016 10:00:55 +0200 Subject: Re: Diskless workstation and some minor issues To: "freebsd-hackers@freebsd.org" References: <57163991.4000100@systella.fr> <1461075243.1232.9.camel@freebsd.org> <20160419161201.GZ2422@kib.kiev.ua> From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= Message-ID: <571DCEB4.1020509@systella.fr> Date: Mon, 25 Apr 2016 10:00:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40 MIME-Version: 1.0 In-Reply-To: <20160419161201.GZ2422@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.1 at rayleigh X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 08:01:12 -0000 Konstantin Belousov a écrit : > On Tue, Apr 19, 2016 at 08:14:03AM -0600, Ian Lepore wrote: >> On Tue, 2016-04-19 at 15:58 +0200, BERTRAND Jo?l wrote: >>> Second trouble. /var/log/message contains a lot of : >>> Apr 9 10:50:00 pythagore atrun[862]: cannot lock /var/at/jobs/: >>> Permission denied >>> >>> > Of course, lockd and statd are running on nfs server. Permission on >>> /var/at are : >>> >>> root@pythagore:/var/at # ls -al >>> total 8 >>> drwxr-xr-x 4 root wheel 512 Aug 12 2015 . >>> drwxr-xr-x 28 root wheel 512 Apr 15 09:14 .. >>> drwxr-xr-x 2 daemon wheel 512 Aug 12 2015 jobs >>> drwxr-xr-x 2 daemon wheel 512 Aug 12 2015 spool >>> root@pythagore:/var/at # >>> >>> > I don't understand where is the mistake. >>> >> >> This is a more serious problem. I have found it to be impossible to >> run a diskless workstation with a persistant /var mounted via NFS >> (either by itself or as a directory within the nfs rootfs). It's been >> this way for several years. You can add varmfs=yes to your rc.conf to >> get a working system, but then you have a non-persistant /var which >> really isn't very useful. >> >> Hmm, but the problems I usually have are with /var/run and pidfiles. >> I've never noticed this /var/at problem (maybe just because I gave up >> trying to run with an nfs-mounted /var before I noticed them). > > I successfully run with nfs-mounted /var (actually, part of the nfs-mounted > root) on my test machines, with the following boot setting: > boot.nfsroot.options="nolockd" > > What you need is the working advisory locks, but since /var is by its > structure, private, there is no need to share locking with the server > or other clients. nolockd makes the client kernel to handle adv locks > autonomously, without lockd/statd protocol. > Sorry for the delay, my diskless FreeBSD workstation is far away... Last saturday, I have added in /boot/loader.conf : hw.usb.no_boot_wait=1 boot.nfsroot.options="nolockd" First line works as expected but if I keep the second one uncommented, FreeBSD doesn't boot anymore. Kernel is loaded and launchs init but dhclient refuses to send DHCP request to server... Regards, JB From owner-freebsd-hackers@freebsd.org Tue Apr 26 02:31:59 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D9E39B0D247 for ; Tue, 26 Apr 2016 02:31:59 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B119A1BFF for ; Tue, 26 Apr 2016 02:31:59 +0000 (UTC) (envelope-from andrey@zonov.org) Received: by mailman.ysv.freebsd.org (Postfix) id B0252B0D245; Tue, 26 Apr 2016 02:31:59 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AFCCCB0D244 for ; Tue, 26 Apr 2016 02:31:59 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 83CBD1BFD for ; Tue, 26 Apr 2016 02:31:59 +0000 (UTC) (envelope-from andrey@zonov.org) Received: by mail-pa0-x22d.google.com with SMTP id zm5so830153pac.0 for ; Mon, 25 Apr 2016 19:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zonov-org.20150623.gappssmtp.com; s=20150623; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=6LmaRlNY00yLIRo6bgAvV+qfwksw35keCVcBTYVRpTU=; b=iHQJaxk2vFcP5cwduxbuA4DQF6Du8YjL/rLGfnCvIVCy7pP+eo+QQ2n1JectLvwFfc VT2Bx/pZJnduECA0jXaylqgLzKKWNTUHckRHWGMkUq/zM+kDipb/ifexkN4ryO+ppDBW SgTETebWGpHPoijSqxoawC7f8Q+OmQ/eVw7uRiRF+Ou0fzlVZFfqhz8TCn9/N8RtIJ3L lFU+08yjaFr66Zh5dibqqRw2PBCY2Zz68nDlf6FtQ2uu+Z6cR57Gx5s95km/sUK9kEpM JevHHCfAhX/IjT0AJWvOJzMHMPGdHT91w/M/NhMzByI8D5zb6oO0PVAE0WwwkDCmj2Ag uX1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to; bh=6LmaRlNY00yLIRo6bgAvV+qfwksw35keCVcBTYVRpTU=; b=EIx9M0mUPQAiVMnQlqstIFFDPvf/2NzhidRoguXcn13EJDrWw3MBvgY8twGwLC/rk8 D3Y8aaf1O+U5z/biCmf5P7nV1LkRPYqvvVw8Q20NFe4ndPI3FMDm7ioHGeM3mWYLDTB+ h6uwATriVA3Letbd/NE9Vz3ARn1/vwgrKnCJpHVNJyXXqHdBLsQR5WR+M0/JzdvpGR6w 1fRZUHxUi4rcI55RAB+LyKBkUlmR6pJkRFLTMNMn6MLkHrGStxunCZZn3PrKEt9OKpdR 20KmG4ks15v9IRTO1JzWa9a8w450w+erYZmAgngr9ntcmBb131qxFtIQU0GO0P+6Ujsz DqPw== X-Gm-Message-State: AOPr4FXLQwKsv5Lq0ONAH4AWciMQ253R8ygt3dznrDTYy3KgOPkX9JuzmWBgsPB7vkyLjQ== X-Received: by 10.66.74.138 with SMTP id t10mr175699pav.22.1461637918573; Mon, 25 Apr 2016 19:31:58 -0700 (PDT) Received: from zont-osx-2.local (c-69-181-251-166.hsd1.ca.comcast.net. [69.181.251.166]) by smtp.googlemail.com with ESMTPSA id t1sm33308704paa.17.2016.04.25.19.31.57 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Apr 2016 19:31:57 -0700 (PDT) Sender: Andrey Zonov Subject: Re: Strange memory management with mmap() To: Dmitry Sivachenko , hackers@freebsd.org References: <3434ED75-7994-4E9E-9B06-FACCD7DC90FF@gmail.com> <15DE3B94-3C09-4855-A274-D5655B049403@gmail.com> From: Andrey Zonov Message-ID: <571ED318.1030402@FreeBSD.org> Date: Mon, 25 Apr 2016 19:31:52 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <15DE3B94-3C09-4855-A274-D5655B049403@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9cEpITkeVCpiagQELbrqNpVNGOTJqQ5b0" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 02:32:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9cEpITkeVCpiagQELbrqNpVNGOTJqQ5b0 Content-Type: multipart/mixed; boundary="H0tpX72hev2JCjPQh7huOmFm9x5V1gTBo" From: Andrey Zonov To: Dmitry Sivachenko , hackers@freebsd.org Message-ID: <571ED318.1030402@FreeBSD.org> Subject: Re: Strange memory management with mmap() References: <3434ED75-7994-4E9E-9B06-FACCD7DC90FF@gmail.com> <15DE3B94-3C09-4855-A274-D5655B049403@gmail.com> In-Reply-To: <15DE3B94-3C09-4855-A274-D5655B049403@gmail.com> --H0tpX72hev2JCjPQh7huOmFm9x5V1gTBo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 7/22/15 5:47 AM, Dmitry Sivachenko wrote: >=20 >> On 16 =D0=B8=D1=8E=D0=BB=D1=8F 2015 =D0=B3., at 21:19, Dmitry Sivachen= ko wrote: >> >>> >>> On 16 =D0=B8=D1=8E=D0=BB=D1=8F 2015 =D0=B3., at 18:42, Dmitry Sivache= nko wrote: >>> >>> Hello! >>> >>> I am using FreeBSD-10-stable and writing a program that uses large da= ta file via mmap() in read only mode. >>> To be specific, I have 256GB RAM machine and typical size of data fil= e is ~160GB (more than 1/2 of RAM and less that the whole RAM). >>> There is no other programs running during the test. >>> >>> Consider the following use case: I have two files on disk. I mmap() = the first one and prefetch data to RAM (touch every page of the file). >>> After that I expect all data to be cached in RAM and subsequent acces= s will be fast. >>> >>> Next I do munmap() on the first file, mmap() the second one and do th= e same test: prefetch data and expect it to be cached in RAM (and some of= the pages belonging to the first file to be purged out, because size_of(= file1)+size_of(file2) > size_of(RAM). >>> >>> Please find my test program attached. >>> >>> I run the program with 2 files provided via command line (both about = 160GB). >>> What I observe in real is: >>> -- before I run the program all RAM is in FREE state as reported by t= op(1). >>> -- after first prefetch() of the first file, all it's data goes to "C= ache" state, RES column of the process remains the same (small) >>> -- second prefetch() works fast as expected, memory goes from Cache t= o Active state, RES column of the process grows up to match file size (SI= ZE=3D=3DRES now) >>> -- now first prefetch() for second file starts: the remaining Free me= mory goes to Cache state, Active size still equals to first file size. >>> -- second prefetch() for second file works as slow as first one, like= if nothing was cached in memory during the first prefetch() run, RES col= umn does not change. >>> >>> >>> Here is the output: >>> % /tmp/a.out file1.dat file2.dat >>> file1.dat... First prefault time: 1235.747351 seconds >>> Second prefault time: 74.893323 seconds >>> Ok. >>> file2.dat... First prefault time: 1316.405527 seconds >>> Second prefault time: 1311.491842 seconds >>> Ok. >>> >> >> >=20 >=20 > I tried the same test program on Linux machine with similar hardware. = It behaves like expected (second prefetch works very fast): >=20 > file1.dat... First prefault time: 2664.621088 seconds > Second prefault time: 1.969283 seconds > Ok. > file2.dat... First prefault time: 2917.009003 seconds > Second prefault time: 34.128762 seconds > Ok. >=20 "Cache" works as a FIFO, so beginning of the second file is out of "Cache" by the the end of first prefault(). Workaround is to do double prefault() for segments, e.g. 1Gb. --=20 Andrey Zonov --H0tpX72hev2JCjPQh7huOmFm9x5V1gTBo-- --9cEpITkeVCpiagQELbrqNpVNGOTJqQ5b0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJXHtMdAAoJEBWLemxX/CvT2DEIAK39gGMSwIPss9vldU8k4PeZ 65+yy0+2G6HGyoh9hTVTuNX6fjENe1f+bNSOpMttokz3zX9nqKbSV3DTIeHaiuak ld1m/Czr6sTrMcguJm523TXqE2piMcD5RBU7Ju+8V8aDyjMJjP+FMxrC6/dpw17e PJox4P8OxY5lTOeSOb/Z0RjmIQZsWVk6WbuifBBy+D9edHlkr5Tplwnw+U+kfRsO 5Dslf77qJ1GQiB6CgYUCrBhvMHej9dRNVnLFqrVym6bFbyTxQa69g1x+XPtM8oFf BRMAmMhJmbiMEpR85WR/vO0V1rH8AkFsrHwFsYw1OkJz5vvYso7uN28jwlVQOfI= =mHsu -----END PGP SIGNATURE----- --9cEpITkeVCpiagQELbrqNpVNGOTJqQ5b0-- From owner-freebsd-hackers@freebsd.org Tue Apr 26 12:54:24 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AE5BEB1C9E5 for ; Tue, 26 Apr 2016 12:54:24 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from mail.embedded-brains.de (mail.embedded-brains.de [82.135.62.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 61C38127C for ; Tue, 26 Apr 2016 12:54:24 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 3918E2A1816 for ; Tue, 26 Apr 2016 14:49:39 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id OQ6rqbLXBv8d for ; Tue, 26 Apr 2016 14:49:37 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id EF1682A183C for ; Tue, 26 Apr 2016 14:49:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id bzjJhQhKQSHX for ; Tue, 26 Apr 2016 14:49:36 +0200 (CEST) Received: from [192.168.96.129] (unknown [192.168.96.129]) by mail.embedded-brains.de (Postfix) with ESMTPSA id B14BA2A1816 for ; Tue, 26 Apr 2016 14:49:36 +0200 (CEST) To: freebsd-hackers@freebsd.org From: Sebastian Huber Subject: UMA alloc with max items < potential items in per processor buckets Message-ID: <571F63BD.1090001@embedded-brains.de> Date: Tue, 26 Apr 2016 14:49:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 12:54:24 -0000 Hello, I don't use FreeBSD directly, but instead a port of the FreeBSD network=20 stack to RTEMS. So, this problem may not apply to FreeBSD. I observed=20 the following problem during an UDP socket create. They are allocated=20 from the following zone: void udp_init(void) { in_pcbinfo_init(&V_udbinfo, "udp", &V_udb, UDBHASHSIZE, UDBHASHSIZE, "udp_inpcb", udp_inpcb_init, NULL, UMA_ZONE_NOFREE, IPI_HASHFIELDS_2TUPLE); V_udpcb_zone =3D uma_zcreate("udpcb", sizeof(struct udpcb), NULL, NULL, NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_NOFREE); uma_zone_set_max(V_udpcb_zone, maxsockets); EVENTHANDLER_REGISTER(maxsockets_change, udp_zone_change, NULL, EVENTHANDLER_PRI_ANY); } In my setup maxsockets is 32. This is probably artificially small=20 compared to a real FreeBSD machine. The system has 24 processors, so we=20 need 128 * 24 items for the per processor cache buckets. This is=20 considerably lager than the single keg of the zone can deliver. Thus in=20 case a processor without a per processor bucket tries to do a=20 uma_zalloc(V_udpcb_zone, M_NOWAIT | M_ZERO), then it will get no item if=20 other processors already consumed all items for their per processor=20 cache buckets. I adjusted the uma_zone_set_max() like this diff --git a/freebsd/sys/vm/uma_core.c b/freebsd/sys/vm/uma_core.c index 845c433..f88d3d3 100644 --- a/freebsd/sys/vm/uma_core.c +++ b/freebsd/sys/vm/uma_core.c @@ -2903,6 +2903,10 @@ uma_zone_set_max(uma_zone_t zone, int nitems) uma_keg_t keg; ZONE_LOCK(zone); +#ifdef SMP + if (nitems < zone->uz_count * mp_maxid) + nitems =3D zone->uz_count * mp_maxid; +#endif keg =3D zone_first_keg(zone); keg->uk_maxpages =3D (nitems / keg->uk_ipers) * keg->uk_ppera; if (keg->uk_maxpages * keg->uk_ipers < nitems) and this seems to fix the problem. Is there an implicit assumption in=20 FreeBSD that the zone max is always large enough to provide items for=20 the per processor cache buckets? --=20 Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch=C3=A4ftliche Mitteilung im Sinne des EHUG= . From owner-freebsd-hackers@freebsd.org Tue Apr 26 20:38:36 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6E8EBB1DA27 for ; Tue, 26 Apr 2016 20:38:36 +0000 (UTC) (envelope-from mseqs@bsd.com.br) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 242E1186F for ; Tue, 26 Apr 2016 20:38:36 +0000 (UTC) (envelope-from mseqs@bsd.com.br) Received: by mail-wm0-x242.google.com with SMTP id w143so7460148wmw.3 for ; Tue, 26 Apr 2016 13:38:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=mime-version:date:message-id:subject:from:to; bh=OfQhglo5Q98kA9PWZl+JUbVJgNtI5xWk2NmQ+SMJht0=; b=C8M3lhHoNN9IaY8gM1QCSNTBEzxe06MeoXMAgaL6IwQtwS3okVBKelMQYL7Uzh7Ojg osdTVnaT2goOLmu2H4Tnf3Dgz9TWr6Ht1Wvlt76O2hAJ+gF6NC9pZulO0x/L0VKzJR0P 3T7H03AUm58TekL5t3l0+hwlruJF+6HzMgPFM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=OfQhglo5Q98kA9PWZl+JUbVJgNtI5xWk2NmQ+SMJht0=; b=M2tdU9vD5L4trEy2eUeSM2VExIThcl43EX8rZsp5M0g45mqz16oZJluCz8QbOrwBU8 6x2IUVyFyWANy7WWAvEbUbHOuvG2pNHgZR+pBcu/OoQDgKTd4rR8pypvHOjpU0zTpEVK yImW0sZQz2wP/3woVot6xcjdTRV1rSRW+2x9w77YbT6xi14OTlsZNo8vjCXVKCRtCEmR PtTfHt9uTex098jMASwZRRYmz0RDmL/93kDEpEQhIHA39qL3yw4/bIwn2e1C9KwVh4p+ Ttxc8WIhxk2k6hOiH6cP9S4+mLT4URBA1u6tJzQjY1NGsuRsoWpskqhlAf4EbOv0cXBv T5JA== X-Gm-Message-State: AOPr4FUCdYfoTdslaQwW2USgRMjGVli79Kn++3RgfFBYQ//uuvLGoLPJGvKUXsx4x39MkuWbQo+SQfOEe4axZQ== MIME-Version: 1.0 X-Received: by 10.194.60.134 with SMTP id h6mr5255435wjr.115.1461703114227; Tue, 26 Apr 2016 13:38:34 -0700 (PDT) Received: by 10.194.53.233 with HTTP; Tue, 26 Apr 2016 13:38:34 -0700 (PDT) Date: Tue, 26 Apr 2016 17:38:34 -0300 Message-ID: Subject: Contributing to FreeBSD From: Rafael Rodrigues Nakano To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 20:38:36 -0000 Hello, I would like to contribute to FreeBSD in terms of code, but I don't know where, exactly. I use most of the time C in my free time hobby projects, but I know a bit of C++ and the concept of OOP. But I found no way to contribute to the system itself, I should study more before entering the Operating System Programming world. However, like I said, I'd like to contribute to FreeBSD, so, should I try to enhance the user-level applications or something like this? (I saw that 'freebsd-version' is a shell script and I think I could make a more information-detailed version in C, or something else). Sorry if it's a really dumb question, I like FreeBSD so much and I know I need to contribute to the development somehow. Is this the correct way (if not, the easiest one) to start contributing to such a great OS project like this? And, finally, how exactly I submit my code? CVS? Git? By email? Thanks in advance. From owner-freebsd-hackers@freebsd.org Tue Apr 26 21:19:13 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2AF22B1D817 for ; Tue, 26 Apr 2016 21:19:13 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from webmail2.jnielsen.NET (webmail2.jnielsen.net [50.114.224.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "webmail2.jnielsen.net", Issuer "freebsdsolutions.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EBC791647 for ; Tue, 26 Apr 2016 21:19:12 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from [192.168.2.210] (c-73-65-219-132.hsd1.ut.comcast.net [73.65.219.132]) (authenticated bits=0) by webmail2.jnielsen.NET (8.15.2/8.15.1) with ESMTPSA id u3QLKJaJ047629 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Apr 2016 15:20:22 -0600 (MDT) (envelope-from lists@jnielsen.net) X-Authentication-Warning: webmail2.jnielsen.net: Host c-73-65-219-132.hsd1.ut.comcast.net [73.65.219.132] claimed to be [192.168.2.210] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Contributing to FreeBSD From: John Nielsen In-Reply-To: Date: Tue, 26 Apr 2016 15:19:02 -0600 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <6451E558-CF19-464F-B71D-6718EFBD5192@jnielsen.net> References: To: Rafael Rodrigues Nakano X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 21:19:13 -0000 On Apr 26, 2016, at 2:38 PM, Rafael Rodrigues Nakano = wrote: > I would like to contribute to FreeBSD in terms of code, but I don't = know > where, exactly. I use most of the time C in my free time hobby = projects, > but I know a bit of C++ and the concept of OOP. But I found no way to > contribute to the system itself, I should study more before entering = the > Operating System Programming world. However, like I said, I'd like to > contribute to FreeBSD, so, should I try to enhance the user-level > applications or something like this? (I saw that 'freebsd-version' is = a > shell script and I think I could make a more information-detailed = version > in C, or something else). Sorry if it's a really dumb question, I like > FreeBSD so much and I know I need to contribute to the development = somehow. Hi! Start here and follow the links, including to the project ideas page and = the PR database (bugzilla): https://www.freebsd.org/doc/en/articles/contributing/ Get involved in the mailing lists, try things out and see what interests = you. If you find (or fix!) bugs, submit problem reports to Bugzilla. You = can also contribute patches to existing PRs. > Is this the correct way (if not, the easiest one) to start = contributing to > such a great OS project like this? >=20 > And, finally, how exactly I submit my code? CVS? Git? By email? As mentioned you can use Bugzilla to submit problem reports and patches. = You can also use it to submit new ports. The mailing lists are appropriate for discussion of new features and = small patches. Larger patches can be submitted to Phabricator = (https://reviews.freebsd.org/) for review. Phabricator is also a good = place to look at other work in progress. The official FreeBSD code repositories are Subversion, but there is a = growing number of people using git. There are now official github repos = for FreeBSD, which are updated regularly from the SVN repos: https://wiki.freebsd.org/GitWorkflow HTH, JN From owner-freebsd-hackers@freebsd.org Tue Apr 26 21:51:38 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E07BFB1C528 for ; Tue, 26 Apr 2016 21:51:38 +0000 (UTC) (envelope-from devin@shxd.cx) Received: from shxd.cx (mail.shxd.cx [64.201.244.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CBA9E162C; Tue, 26 Apr 2016 21:51:38 +0000 (UTC) (envelope-from devin@shxd.cx) Received: from 50-196-156-133-static.hfc.comcastbusiness.net ([50.196.156.133]:53504 helo=tinkerbell.pixel8networks.com) by shxd.cx with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1av2NE-0006lU-F5; Tue, 26 Apr 2016 05:45:52 -0700 From: Devin Teske Subject: Phabricator Badges Date: Tue, 26 Apr 2016 14:51:37 -0700 Message-Id: <8AC02865-DB49-4250-9D69-40BBC686F2B1@freebsd.org> Cc: Devin Teske To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Sender: devin@shxd.cx Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 21:51:39 -0000 Once upon a time (circa July 2015) we had badges in Phabricator. E.g., https://reviews.freebsd.org/badges/recipients/4/ = However, they seem to be gone. Was there any particular reason why? I was recently going to use us as an example to show why Phab may be = better than what we use at $work (ReviewBoard). --=20 Devin= From owner-freebsd-hackers@freebsd.org Wed Apr 27 19:21:51 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 81D6FB1F846 for ; Wed, 27 Apr 2016 19:21:51 +0000 (UTC) (envelope-from zclaudio@bsd.com.br) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1D80018F2 for ; Wed, 27 Apr 2016 19:21:51 +0000 (UTC) (envelope-from zclaudio@bsd.com.br) Received: by mail-wm0-x231.google.com with SMTP id g17so820086wme.0 for ; Wed, 27 Apr 2016 12:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=mime-version:date:message-id:subject:from:to; bh=Q8IRVzs/ZKm1BX+Xq5kZtZv9ApiKaVzDGvkZsXp7E/U=; b=MfWSDWx5pyjMDOHsYPfX0DWpfQjYTUbdbPjnVkJ8SlxhO0qoGQaFgeWZudqsXFnnNP 6nXPhJ5SyogG3kgDqFHKxEI/XmMO1k/+LbLhUZ2NCgcDlxlwEMt7zzIoXB1junIODEt4 aXHO8BedTaj72mShJxnlRdbfc/kwtkqIwcO/k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=Q8IRVzs/ZKm1BX+Xq5kZtZv9ApiKaVzDGvkZsXp7E/U=; b=RgRtHFf3EeLvi/FjHKGDXwyjN0fokGaZzOgJI8tZ/jAiOjceTj95IPKSbCLvx6fr1y UWudCcGkcRLfUDPiKuBK8ZtbqNzN4uHQsboilJhjAU1w1e6w8Z2ndOGCNDm70BI/bugC ehLAhWOL62nGtCXmKrLQl4rX2HaWpAeugsCYNC0YkQjKD4ltwgy5baS1ckSHl6FuHwzb N46i17ujKvxO5ApDXtIenuiwe7g18kXWhSLSL+M6jJ0VQARefQ5i0zkPEIKCfVITrkxq 4CfB/sz7HRy8NQRB8I1lOf3Je0UkWBxzfnJ8ICdXYmpSpGBQusHyhaPKNZP2sFAlg3zU Oo5Q== X-Gm-Message-State: AOPr4FUlQLNd8SyXSTALY3IMdii0XpPIHKV54VdJPaNkbFLXF4j/2V3Ec56h8ubpZp1YEiurrl+DDxi5UNlHrg== MIME-Version: 1.0 X-Received: by 10.28.60.5 with SMTP id j5mr11640778wma.47.1461784909692; Wed, 27 Apr 2016 12:21:49 -0700 (PDT) Received: by 10.28.183.131 with HTTP; Wed, 27 Apr 2016 12:21:49 -0700 (PDT) Date: Wed, 27 Apr 2016 16:21:49 -0300 Message-ID: Subject: Best option to process packet ACL From: =?UTF-8?Q?Z=C3=A9_Claudio_Pastore?= To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 19:21:51 -0000 Hello everyone, I would like to hear your suggestion regarding the best approach to process IP packets for filtering, in such a way I can avoid lowering my pps rate. Today a have a simple application proxies http application. It's dual threaded on a 4 core system with low CPU power. The current application uses two threads, one for control and one for data flow processing. I need to implement a simple set of stateless filtering, I will process only: - src-ip - dst-ip - src-port - dst-port - iplen - proto (tcp/udp/other) My current rate of requests per second is high, around 200K. I have no idea how I can leverage the IDLE CPUs the best way to implement this ACL filtering trying not to impact on the pps rate I have today. I have implemented it serial today (not threaded) and I get 40% performance loss. I will handle max 128 filter rules, this is a decision which is made. This is going to be first match wins. My current plans are to test: 1) Create 6 threads, one to test each aspect of the ACL (src-ip, dst-ip, etc) the first thread that returns false to parent thread I stop processing that rule and go to the next, and tell all other threads to die/exit since they don't matter anymore. 2) Create one thread to process a batch of rules, say, 8 rules per thread per request. Don't know if I would limit total number of threads and lock requests while threads ar e busy. 3) Someone suggested "do as pf/ipfw do" but I have no idea how it's done, how multithreaded it is and what is done on each thread. 4) Other suggestion? This is going to run FreeBSD 11, I use libevent2 on the current application so far. Thanks. From owner-freebsd-hackers@freebsd.org Wed Apr 27 20:48:41 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 28CF2B1EE5E for ; Wed, 27 Apr 2016 20:48:41 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B6B16139C for ; Wed, 27 Apr 2016 20:48:40 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: by mail-wm0-x22e.google.com with SMTP id e201so54176788wme.0 for ; Wed, 27 Apr 2016 13:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=a7AMFuVvKSyWGYsN2iGJ3Kn7+gpfkJ7Qq2143GAgdKY=; b=J9XAfYu+jLeMRuG0G8PL3uDhQgtiElC0193LCbmE9I5Uebjp/8zMVx8Bq9FQ/zdtrd bNNTfnIdnJMSfhCCUzv59mSxJuLepEZLKBMx7qw1ey0fWXTPrpwUdWW/TcHgjYhoUxek WF1xaW/1jtlVMA6yUOW+QgKEAiyyPjyjoRcbSo8XcPxdMskMhw60Ol7hELGxt+dqh/Wu EtZOoGCWCq7nlas7wAK9F6Xzh7ECU0jON/c3HWysS7lrBH5xPAeyNqv6g6+VCJTiqTK/ Dc62FVRo1utAi6Nf94PdpXmoqthVU6oVjDl+AryXA/VcUDVZGSTyAm5uUZWRWIVApySw u69Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=a7AMFuVvKSyWGYsN2iGJ3Kn7+gpfkJ7Qq2143GAgdKY=; b=Uon73DQSHBLc7bI/6vIbYhPpNB5+sx2gBJMWvvUq92rbo9ZsQBdX5FMgzuofMBePzm btfDBIzTFQHIKv0vSw6BnAIaXszmQ4tvIdzB4cSKGfRKH6aVI9prY45z7wam+QOUkzaR 7X8TYQwTQEWzwf+Jm2dPkIHDvKNm6jwZWaRcECP4QR1HqXv+R0W/UNVw6OMw8B0UNyDv 6UGYNWw9+af63YCK67v0om2sgjTjnTA4buPtXpS2KG95U8J2zcthPRjeVBqNuzPEaJuN Gl+rOJdtxyjCJwjTSFbxh8gwrj4oaOUh2AZTR8cmUstTfJJwLIl0AHcE49YHvp33cC/8 Lf1Q== X-Gm-Message-State: AOPr4FWlvZAO/2xGbTln2YtZtn9IWg62+lKMJDHbJ5PDNzuoE89RB8R/74DExVo1QJUEPQ== X-Received: by 10.194.143.51 with SMTP id sb19mr11530640wjb.98.1461790119407; Wed, 27 Apr 2016 13:48:39 -0700 (PDT) Received: from gumby.homeunix.com ([2.222.64.48]) by smtp.gmail.com with ESMTPSA id b15sm31105529wmd.1.2016.04.27.13.48.37 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Apr 2016 13:48:38 -0700 (PDT) Date: Wed, 27 Apr 2016 21:48:36 +0100 From: RW To: freebsd-hackers@freebsd.org Subject: Re: Strange memory management with mmap() Message-ID: <20160427214836.05631eec@gumby.homeunix.com> In-Reply-To: References: X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd10.2) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 20:48:41 -0000 On Thu, 16 Jul 2015 18:42:26 +0300 Dmitry Sivachenko wrote: > I run the program with 2 files provided via command line (both about > 160GB). What I observe in real is: > -- before I run the program all RAM is in FREE state as reported by > top(1). -- after first prefetch() of the first file, all it's data > goes to "Cache" state, This is what surprises me most, I'd expect it to go to active. I thought that the point of the cache queue is that its pages can be reassigned because they are clean and not mapped anywhere. >RES column of the process remains the same > (small) -- second prefetch() works fast as expected, memory goes from > Cache to Active state, RES column of the process grows up to match > file size (SIZE==RES now) -- now first prefetch() for second file > starts: the remaining Free memory goes to Cache state, Active size > still equals to first file size. -- second prefetch() for second file > works as slow as first one, like if nothing was cached in memory > during the first prefetch() run, RES column does not change. > > Here is the output: > % /tmp/a.out file1.dat file2.dat > file1.dat... First prefault time: 1235.747351 seconds > Second prefault time: 74.893323 seconds > Ok. > file2.dat... First prefault time: 1316.405527 seconds > Second prefault time: 1311.491842 seconds > Ok. > > I treat this like the bug somewhere in virtual memory management. The timings do make sense. The management of the active queue isn't LRU, it takes account of how many times a page gets accessed. Whatever is going on with the cache queue doesn't seem to change that general strategy. The double prefail on the first file means that all its pages are in memory and have recently been accessed twice. When the system runs out of free memory the VM system retains the file1 pages at the expense of the pages from file2 which have only been accessed once. At the end of the first pass only the end of file2 is cached, which isn't any use on the second pass because the prefault works upwards. This is an uncommon pattern of access where simple LRU expiry of the cache will outperform anything more sophisticated. I don't think it matters that Linux does better on this particular benchmark. From owner-freebsd-hackers@freebsd.org Wed Apr 27 21:48:06 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 79ADEB1FCB7 for ; Wed, 27 Apr 2016 21:48:06 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4C88B170C for ; Wed, 27 Apr 2016 21:48:05 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yuri.doctorlan.com (c-73-71-174-75.hsd1.ca.comcast.net [73.71.174.75]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id u3RLJh0m063882 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 27 Apr 2016 14:19:44 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-73-71-174-75.hsd1.ca.comcast.net [73.71.174.75] claimed to be yuri.doctorlan.com To: Freebsd hackers list From: Yuri Subject: Brief and intermittent system freezes Message-ID: <57212CEC.6050105@rawbw.com> Date: Wed, 27 Apr 2016 14:19:40 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 21:48:06 -0000 I changed the motherboard on the 10.3 desktop system and now I am getting the "sticky mouse" effect: mouse briefly freezes every few seconds. I think USB mouse events aren't propagated to the Xorg process in a timely fashion. This also possibly makes the system impaired in some other ways too. One thing I can think of is that the network driver changed from re(4) to msk(4). What is the best way to troubleshoot such problem? Anybody experiences something similar? Thanks, Yuri From owner-freebsd-hackers@freebsd.org Thu Apr 28 14:26:40 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B0E45B1FEB3; Thu, 28 Apr 2016 14:26:40 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A935168E; Thu, 28 Apr 2016 14:26:40 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: by mail-vk0-x231.google.com with SMTP id a5so33280130vkg.0; Thu, 28 Apr 2016 07:26:40 -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; bh=kOEsk3knbYVlnW1gXE0PUnhAEn32XPQE7DH3ZJNDn1Y=; b=JuAB3ZcWWg/FobLL8QP+y+qluXJYQlYG1CVyPeAr/BRNkmrdXW8BdgebetWHkg/hQT 9ElqJfHLB2DvM9C8FH1Zxi7oV3hl6K0nqSkr3OZt8nQzIOmYL2O83Xm8dowg3UgzdkaO w8DD9ete8GPLRANdUX3necMPIfJBIEDIl/GFyMWksh2NA00MaUtcnLhCkw84msfqoKy/ nh7kg+OO+ri4wRO/BjPXQ2kxyNBHvwxd7fqEIePcQfe6823bobixidCOdYKkSbbAUHoZ O+qAOFV3QmWLNhNV2Q5w1qT7BeK+AOlgoOofBHhgUq3zDkI9mfEkF6CyWXFmnRNnIMX0 jxCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=kOEsk3knbYVlnW1gXE0PUnhAEn32XPQE7DH3ZJNDn1Y=; b=JR4NwE+bpBmLJdThtU3ozPJ+DSCj/o+jgtYTcpELCbCahd3daCq7jSl2emlBtiL80Q 4xgbSxWLWNiGO8X4Y/Pohc79Ai0mfRv7vHrbOY6Kp4HttoSH23VgSew2OYFz53VDYlEY RerItc0HkILzoj5Xqc1dbUqrdsgu1CLHk6uXHjXNSY4NbLMx39gWsni8uBhgjGSOeIiT fdCTkVoyMCiQjroJi4H5ODcl4VhdzD47TNm2FBENtzBoNPv9Rn/DT6U9OHq5QuQU/0s9 yc6w//+wUfx2b3hLd9WAzaxnIR/SUJDR0Y25nO1tce06Iz2GUfe45aoFi2epaqj3x13z fbGw== X-Gm-Message-State: AOPr4FUcUSMhT70Z7J7iGK9wwWOuF6bAAp1jNAwTeZ9NvqleH+jmrX2N5pOx0vFUoM1mBqVDobK9ybHWJQkSYg== MIME-Version: 1.0 X-Received: by 10.31.231.68 with SMTP id e65mr2505309vkh.58.1461853599357; Thu, 28 Apr 2016 07:26:39 -0700 (PDT) Received: by 10.103.21.135 with HTTP; Thu, 28 Apr 2016 07:26:39 -0700 (PDT) Date: Thu, 28 Apr 2016 10:26:39 -0400 Message-ID: Subject: Has this ever been considered for video on raspberry devices and for other architectures? From: Joe Nosay To: Adrian Chadd , FreeBSD Hackers , freebsd-current , freebsd-arch , Dru Lavigne Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 14:26:40 -0000 Is it possible to use https://github.com/raspberrypi/userland along with TinyX/XBMC to create an accelerated graphics driver? From owner-freebsd-hackers@freebsd.org Thu Apr 28 14:51:00 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9768CB1F471 for ; Thu, 28 Apr 2016 14:51:00 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5BC4C13C5 for ; Thu, 28 Apr 2016 14:51:00 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi0-x236.google.com with SMTP id x19so85954820oix.2 for ; Thu, 28 Apr 2016 07:51: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; bh=6nUnKlLvuBWxxOn3B7vaQr4f8CNSDQGqnKZmE6We8tQ=; b=ZRYtaIQwtVKh886vwfXMYgWYQOE5U1K4VtrHmbhQmBdtDHDMhBBsjYSfyrTp75OHZA YGptZ5vL6edsAJbPJkbx6zOba9+/eipM+Sc/WPSiJTd1F/TYBMDu67rcuik+mpCMRfqk 5p9xIv8yXEJRaS6M9kyBuxCUpEI9+NUcBmw0hH67hNf9c5GHOxZnMxzknkVYst676ffo WLPDhOfU7//aFn2GhIiE5EXEGrHRjwxEOzgOmes05UzbDTRKa5yrrHZtaueJq6zk5Bxz H/ktXTi+J120ALDb81mxZ2Z1Pe5a8G9ShxMgTdvT9Y3YGl/HcgGAA4O2G+oXV7RZ8eeK mClQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=6nUnKlLvuBWxxOn3B7vaQr4f8CNSDQGqnKZmE6We8tQ=; b=BX+twFXJnE3emPR5YDL0qtXf8AXYScQ/bwtcOpnfd1a1SHOoA5CVasyCtnn/fjhgPP 8/zKOyP2UkkeaHStpp09TLzUMWtXubgQjNqjqcFPy2eUDgp06mdxO4t63ikaW5ztDyXQ vg5Z5YUKivpOReSG3yjp4/ySAYz6yv5i3vBkAcyMw7n8+OZYNVVxeXnLme5CzT6xutIE mJ89G1xCD//nTBsmiTIZSXcm3zM5DLETgcU0HU3eXO5epGH4mtI6daXI1qWh2kWOma6T OC1AlR1xkEkxmL/MjAs8hH/XLX437dAsb+pQGe4X5uEB/U0l+IoRfVIYIUzbYTRrUqfR wE/Q== X-Gm-Message-State: AOPr4FWO0dqQq2NU4e2p2YQtkFbsj6yBoDO3xZ3Cpny0qD5SU4LZyFQb+tjCIoVl8Cj1Z/lPKDiKLO2XkZ1lOw== MIME-Version: 1.0 X-Received: by 10.157.38.40 with SMTP id a37mr7343618otb.152.1461855059696; Thu, 28 Apr 2016 07:50:59 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.202.64.138 with HTTP; Thu, 28 Apr 2016 07:50:59 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 Apr 2016 08:50:59 -0600 X-Google-Sender-Auth: py33b7vvEgF-J1e-EIZy6vyt1Jo Message-ID: Subject: Re: Best option to process packet ACL From: Alan Somers To: =?UTF-8?Q?Z=C3=A9_Claudio_Pastore?= Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 14:51:00 -0000 On Wed, Apr 27, 2016 at 1:21 PM, Z=C3=A9 Claudio Pastore wrote: > Hello everyone, > > I would like to hear your suggestion regarding the best approach to proce= ss > IP packets for filtering, in such a way I can avoid lowering my pps rate. > > Today a have a simple application proxies http application. It's dual > threaded on a 4 core system with low CPU power. The current application > uses two threads, one for control and one for data flow processing. > > I need to implement a simple set of stateless filtering, I will process > only: > > - src-ip > - dst-ip > - src-port > - dst-port > - iplen > - proto (tcp/udp/other) > > My current rate of requests per second is high, around 200K. I have no id= ea > how I can leverage the IDLE CPUs the best way to implement this ACL > filtering trying not to impact on the pps rate I have today. > > I have implemented it serial today (not threaded) and I get 40% performan= ce > loss. I will handle max 128 filter rules, this is a decision which is mad= e. > This is going to be first match wins. > > My current plans are to test: > > 1) Create 6 threads, one to test each aspect of the ACL (src-ip, dst-ip, > etc) the first thread that returns false to parent thread I stop processi= ng > that rule and go to the next, and tell all other threads to die/exit sinc= e > they don't matter anymore. > > 2) Create one thread to process a batch of rules, say, 8 rules per thread > per request. Don't know if I would limit total number of threads and lock > requests while threads ar e busy. > > 3) Someone suggested "do as pf/ipfw do" but I have no idea how it's done, > how multithreaded it is and what is done on each thread. > > 4) Other suggestion? > > This is going to run FreeBSD 11, I use libevent2 on the current applicati= on > so far. > > Thanks. > _______________________________________________ > > Is there some reason why you can't simply use pf or ipfw? ipfw can do everything you described. pf can do most of it, but I'm not sure if pf can filter on iplen. If I were you, I wouldn't attempt to write my own userland firewall until I was absolutely sure that neither pf nor ipfw would work. If that's the case, then I would try using diverter sockets. With a diverter socket, pf or ipfw does most of the work, but when it encounters a packet it can't process it pushes it up to a userland helper. The userland helper processes the packet and then tells pf or ipfw what to do with it. In realistic applications, pf or ipfw also creates a temporary rule based on the userland helper's decision. Applying the temporary rule in the future is far faster than invoking the userland helper. After a certain amount of time, the temporary rule will expire again. Here's an example in action: http://daemonforums.org/showthread.php?t=3D8846 -Alan From owner-freebsd-hackers@freebsd.org Thu Apr 28 17:20:05 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4E846B1F8AD for ; Thu, 28 Apr 2016 17:20:05 +0000 (UTC) (envelope-from zclaudio@bsd.com.br) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DB75F11D5 for ; Thu, 28 Apr 2016 17:20:04 +0000 (UTC) (envelope-from zclaudio@bsd.com.br) Received: by mail-wm0-x231.google.com with SMTP id e201so84944256wme.0 for ; Thu, 28 Apr 2016 10:20:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=o6WpFxMkpMTB0ydlNtOhUZS15v0+YuQZ+jihMtMpncI=; b=gA2JbyWhZ6WYNW1w8SjMRJ4aQAFwIZoIgfHp0xuEwnVYSgaXL1UWCX7UneoxY10xNs VQSWtPUuOzh6+1vOxTApGM5u4dQRFJfxVJt6KNyESrMQDKowMv0KAJt/Z/aFR4Z/447k 1v1aJ+lxQ0NBDry710y6KbARB/rDO4Yal9t3M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=o6WpFxMkpMTB0ydlNtOhUZS15v0+YuQZ+jihMtMpncI=; b=GSutG1lgsMpryhnGHET0s3A3DgY4lFG5dzLfs+Gf+FRmEQbCMqMopuUoQGPcfipYdb aDZk818zLbkgmtJcvNLHPSxqClrbY1Bef+2OM/dXvXRtTKClbsrDZNp8GLQATuJWJ0wy JmaSxHNH8/Ew04AYjkxh1qXz/YdnIOyNfvqV9pzY4AT4Ft66gFGKdCiv0FZyMf4b8XMu dQ/0Hace5LsKYStvCBCFv81KQf7n1qBvzIIwmjJT22Qt2VL9j9DyHhY6RRj9PD15pUQW cmeXQHEpZv0sm4kxkQj4PMfs4QgA3coDMCL3yxzzCnGR5QwS98yN5/NFX+NuTKCD3oBl 5vDw== X-Gm-Message-State: AOPr4FXURhbczp8g/EoAqxwOgCLOpOUYgyyX7SJAKTe27xXJIXRdVElorv4Pk5YGJtVBAimmvIJGkFiZ5G5rIg== MIME-Version: 1.0 X-Received: by 10.28.157.143 with SMTP id g137mr17698929wme.29.1461864002779; Thu, 28 Apr 2016 10:20:02 -0700 (PDT) Received: by 10.28.183.131 with HTTP; Thu, 28 Apr 2016 10:20:02 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 Apr 2016 14:20:02 -0300 Message-ID: Subject: Re: Best option to process packet ACL From: Ze Claudio Pastore To: Alan Somers Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 17:20:05 -0000 Because actually, this is ot a packet firewall. When I mentioned pf/ipfw is only to reffer to ideas on how to best match each acl criteria. But my userland application is a proxy, ACL will handle L7 requests within the packets. I will filter based on the mentioned criteria but it will be processed at a different moment unrelated to packet in kernel. It's also DPDK enabled so it's mostly skipping the whole kernel. 2016-04-28 11:50 GMT-03:00 Alan Somers : > On Wed, Apr 27, 2016 at 1:21 PM, Z=C3=A9 Claudio Pastore > wrote: > >> Hello everyone, >> >> I would like to hear your suggestion regarding the best approach to >> process >> IP packets for filtering, in such a way I can avoid lowering my pps rate= . >> >> Today a have a simple application proxies http application. It's dual >> threaded on a 4 core system with low CPU power. The current application >> uses two threads, one for control and one for data flow processing. >> >> I need to implement a simple set of stateless filtering, I will process >> only: >> >> - src-ip >> - dst-ip >> - src-port >> - dst-port >> - iplen >> - proto (tcp/udp/other) >> >> My current rate of requests per second is high, around 200K. I have no >> idea >> how I can leverage the IDLE CPUs the best way to implement this ACL >> filtering trying not to impact on the pps rate I have today. >> >> I have implemented it serial today (not threaded) and I get 40% >> performance >> loss. I will handle max 128 filter rules, this is a decision which is >> made. >> This is going to be first match wins. >> >> My current plans are to test: >> >> 1) Create 6 threads, one to test each aspect of the ACL (src-ip, dst-ip, >> etc) the first thread that returns false to parent thread I stop >> processing >> that rule and go to the next, and tell all other threads to die/exit sin= ce >> they don't matter anymore. >> >> 2) Create one thread to process a batch of rules, say, 8 rules per threa= d >> per request. Don't know if I would limit total number of threads and loc= k >> requests while threads ar e busy. >> >> 3) Someone suggested "do as pf/ipfw do" but I have no idea how it's done= , >> how multithreaded it is and what is done on each thread. >> >> 4) Other suggestion? >> >> This is going to run FreeBSD 11, I use libevent2 on the current >> application >> so far. >> >> Thanks. >> _______________________________________________ >> >> > Is there some reason why you can't simply use pf or ipfw? ipfw can do > everything you described. pf can do most of it, but I'm not sure if pf c= an > filter on iplen. If I were you, I wouldn't attempt to write my own > userland firewall until I was absolutely sure that neither pf nor ipfw > would work. If that's the case, then I would try using diverter sockets. > With a diverter socket, pf or ipfw does most of the work, but when it > encounters a packet it can't process it pushes it up to a userland helper= . > The userland helper processes the packet and then tells pf or ipfw what t= o > do with it. In realistic applications, pf or ipfw also creates a tempora= ry > rule based on the userland helper's decision. Applying the temporary rul= e > in the future is far faster than invoking the userland helper. After a > certain amount of time, the temporary rule will expire again. > > > Here's an example in action: > http://daemonforums.org/showthread.php?t=3D8846 > > -Alan > From owner-freebsd-hackers@freebsd.org Thu Apr 28 17:35:12 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4CEF9B1FCAF for ; Thu, 28 Apr 2016 17:35:12 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 101EE1AD7 for ; Thu, 28 Apr 2016 17:35:12 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi0-x229.google.com with SMTP id v145so58265542oie.0 for ; Thu, 28 Apr 2016 10:35:12 -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; bh=1yhJfbyN1NTccCmq12hWNbNu3oqrMqry6eCEGx9KNvE=; b=GK6hAhlRj8TLuAaoMCjYLsLcSlx8MTr+EuLfrmuxSe6PmWzLaeColzDnO39/HnU6hj tj440SmyOeFNPmLPQFpqX+If4CTWLbqo33ENgWZ0w75vsYai+oYS42oP3zlJMm6eF9aQ U3ZDB38So9k5ck0TypuKBIK44187pJHHlf2nTdqKzrmHROzbMF9lBXcl1gXktlBE4X8X pD6YuVGZCdVFzlhe2K1+Y/6MBmG533hAwiXC/xOgdzGn4GgfLANN4mJU+QFJNBVgVnqW q7GBhJKxNTXkxfQ/HxZk9O1lsavjG+D0v4UyyxDbM1eTJm46tv3ybRbS4hUEZp//pgtM 0ASQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=1yhJfbyN1NTccCmq12hWNbNu3oqrMqry6eCEGx9KNvE=; b=kS+Ton0IreOHTdhUhCyLK42jsZz8vbXO4VXYku76tkCkS211qUn2HtzHKk5waRpRsj tcSp4IIHm0YgMOrXIp0a9qIx+VpkQ9hLz10wPV5bHUuGT0ZPuQLam+ZDrqq+YInKcU9G w7ZdWkbG8eEXg239Qn5fG6xEJEUyN2UyINntjW5Z9fcGkUyDOwL+R8+TgF8iK1i8TghK kvrZjSG8ETefmMH01x9lPcmlvq7pWqXOgklf+oeDn8Hi7T4pYS/pKMdxJiRezYAry1Lh Ed5b3wydYOKCuRkhIsryO6+pMqepNWKFRwEHmmbYOTz0ghKGhdgQ2M0tojC8M9ggnEr5 4o9Q== X-Gm-Message-State: AOPr4FWU99ys5fhVf0pbftDVq8/Czm5dR1VL4r2DpgnKYzGw9z//yqb8bvEAc1kjht/DD5f+PkaUQmUes6qVPw== MIME-Version: 1.0 X-Received: by 10.157.12.210 with SMTP id o18mr7518883otd.192.1461864911192; Thu, 28 Apr 2016 10:35:11 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.202.64.138 with HTTP; Thu, 28 Apr 2016 10:35:11 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 Apr 2016 11:35:11 -0600 X-Google-Sender-Auth: IhdkwZykjZEZoE0TQ7J6s1V4O_o Message-ID: Subject: Re: Best option to process packet ACL From: Alan Somers To: Ze Claudio Pastore Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 17:35:12 -0000 Even if your application is not a traditional firewall, using pf or ipfw would save much development time compared to writing your own packet filter. They can be configured to do things like redirect packets to different ports. You can use that to offload packet filtering from your application to the firewall, and open multiple sockets in your application to receive prefiltered packets. Of course, pf/ipfw can't be used in combination with DPDK, as you discovered. Doesn't DPDK provide access to each queue of a multiqueue NIC? If so, you can create multiple filtering threads, and associate each thread to a single queue of your NIC. Good luck, you've got a lot of work ahead of you. On Thu, Apr 28, 2016 at 11:20 AM, Ze Claudio Pastore wrote: > Because actually, this is ot a packet firewall. > > When I mentioned pf/ipfw is only to reffer to ideas on how to best match > each acl criteria. > > But my userland application is a proxy, ACL will handle L7 requests withi= n > the packets. I will filter based on the mentioned criteria but it will be > processed at a different moment unrelated to packet in kernel. It's also > DPDK enabled so it's mostly skipping the whole kernel. > > > > 2016-04-28 11:50 GMT-03:00 Alan Somers : > >> On Wed, Apr 27, 2016 at 1:21 PM, Z=C3=A9 Claudio Pastore >> wrote: >> >>> Hello everyone, >>> >>> I would like to hear your suggestion regarding the best approach to >>> process >>> IP packets for filtering, in such a way I can avoid lowering my pps rat= e. >>> >>> Today a have a simple application proxies http application. It's dual >>> threaded on a 4 core system with low CPU power. The current application >>> uses two threads, one for control and one for data flow processing. >>> >>> I need to implement a simple set of stateless filtering, I will process >>> only: >>> >>> - src-ip >>> - dst-ip >>> - src-port >>> - dst-port >>> - iplen >>> - proto (tcp/udp/other) >>> >>> My current rate of requests per second is high, around 200K. I have no >>> idea >>> how I can leverage the IDLE CPUs the best way to implement this ACL >>> filtering trying not to impact on the pps rate I have today. >>> >>> I have implemented it serial today (not threaded) and I get 40% >>> performance >>> loss. I will handle max 128 filter rules, this is a decision which is >>> made. >>> This is going to be first match wins. >>> >>> My current plans are to test: >>> >>> 1) Create 6 threads, one to test each aspect of the ACL (src-ip, dst-ip= , >>> etc) the first thread that returns false to parent thread I stop >>> processing >>> that rule and go to the next, and tell all other threads to die/exit >>> since >>> they don't matter anymore. >>> >>> 2) Create one thread to process a batch of rules, say, 8 rules per thre= ad >>> per request. Don't know if I would limit total number of threads and lo= ck >>> requests while threads ar e busy. >>> >>> 3) Someone suggested "do as pf/ipfw do" but I have no idea how it's don= e, >>> how multithreaded it is and what is done on each thread. >>> >>> 4) Other suggestion? >>> >>> This is going to run FreeBSD 11, I use libevent2 on the current >>> application >>> so far. >>> >>> Thanks. >>> _______________________________________________ >>> >>> >> Is there some reason why you can't simply use pf or ipfw? ipfw can do >> everything you described. pf can do most of it, but I'm not sure if pf = can >> filter on iplen. If I were you, I wouldn't attempt to write my own >> userland firewall until I was absolutely sure that neither pf nor ipfw >> would work. If that's the case, then I would try using diverter sockets= . >> With a diverter socket, pf or ipfw does most of the work, but when it >> encounters a packet it can't process it pushes it up to a userland helpe= r. >> The userland helper processes the packet and then tells pf or ipfw what = to >> do with it. In realistic applications, pf or ipfw also creates a tempor= ary >> rule based on the userland helper's decision. Applying the temporary ru= le >> in the future is far faster than invoking the userland helper. After a >> certain amount of time, the temporary rule will expire again. >> >> >> Here's an example in action: >> http://daemonforums.org/showthread.php?t=3D8846 >> >> -Alan >> > > From owner-freebsd-hackers@freebsd.org Thu Apr 28 17:46:50 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32D60B1FED4 for ; Thu, 28 Apr 2016 17:46:50 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0A5131F71 for ; Thu, 28 Apr 2016 17:46:49 +0000 (UTC) (envelope-from jim@netgate.com) Received: by mail-oi0-x22c.google.com with SMTP id x201so91872754oif.3 for ; Thu, 28 Apr 2016 10:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netgate.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FwsFXDWdAZt/axwBTNnReuEteJVSK+p4uq71JnmFnrs=; b=at4YvZspzVpWB0/Q10SW7fR0EJLzu+ctsG4rFah9nXPiz98A5e/54IMg6APPEDE9wq RPjw/LnYg6OtiabgGq6wCIcHwY6OE2PenjYfLbcx+77m8/6exrHnbI5OLARavdSbhz0i i94DXuk7PcvU4wBmkgFv++Zcq9+EnZMcEeqXk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FwsFXDWdAZt/axwBTNnReuEteJVSK+p4uq71JnmFnrs=; b=XJBuQstVpJwp1eqzz221fXhNVT+z7DaGaQrAcfHc9/DnlthleFM7LQycy49RG7QFyr lkQEwvG24JrB2bRzzATZec0b72sIIpg77lnHwBl19KLXnMjBLDmhKu5ozTO94W3/NaS+ EE70QwNNmBWZV0RQYxM/hcEOhs0DI61Mk6JIuD3LVUT6udUXS4S9ccyNsDE7/cSf4B7X 2TOzbglJGXPmlkrOMhDwmMCZwMu6waN2UPr3qUjEliBPQTUb4j/tTcg6cKDsFFHuKXYF NeoHJwSyXKUqTUHXhpvoBLs2NAbZGUrzxYCoCwqT20+EX1qO6JJ8bQzwOcJES7IH8wPj Wj4A== X-Gm-Message-State: AOPr4FUHXxqIOmxr04qAxMGLgwV2XEc1zgb9I94hK04wIXkEf9l5bpKVodoaVzZgX0NJxnpV X-Received: by 10.157.46.196 with SMTP id w62mr7898089ota.7.1461865609186; Thu, 28 Apr 2016 10:46:49 -0700 (PDT) Received: from jims-mbp.netgate.com ([208.123.73.28]) by smtp.gmail.com with ESMTPSA id p203sm3166325oif.16.2016.04.28.10.46.47 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 28 Apr 2016 10:46:47 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Best option to process packet ACL From: Jim Thompson In-Reply-To: Date: Thu, 28 Apr 2016 12:46:46 -0500 Cc: Ze Claudio Pastore , "freebsd-hackers@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Alan Somers X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 17:46:50 -0000 If your application is already using DPDK then: 1) it=E2=80=99s not =E2=80=9Cmostly bypassing the kernel=E2=80=9D, it = *is* bypassing the kernel. 2) ACLs are already a thing in DPDK: = http://dpdk.org/doc/guides/prog_guide/packet_classif_access_ctrl.html 200Kpps is not a lot of load for even =E2=80=98pf=E2=80=99 on slow = hardware. > On Apr 28, 2016, at 12:35 PM, Alan Somers wrote: >=20 > Even if your application is not a traditional firewall, using pf or = ipfw > would save much development time compared to writing your own packet > filter. They can be configured to do things like redirect packets to > different ports. You can use that to offload packet filtering from = your > application to the firewall, and open multiple sockets in your = application > to receive prefiltered packets. >=20 > Of course, pf/ipfw can't be used in combination with DPDK, as you > discovered. Doesn't DPDK provide access to each queue of a multiqueue > NIC? If so, you can create multiple filtering threads, and associate = each > thread to a single queue of your NIC. >=20 > Good luck, you've got a lot of work ahead of you. >=20 > On Thu, Apr 28, 2016 at 11:20 AM, Ze Claudio Pastore = > wrote: >=20 >> Because actually, this is ot a packet firewall. >>=20 >> When I mentioned pf/ipfw is only to reffer to ideas on how to best = match >> each acl criteria. >>=20 >> But my userland application is a proxy, ACL will handle L7 requests = within >> the packets. I will filter based on the mentioned criteria but it = will be >> processed at a different moment unrelated to packet in kernel. It's = also >> DPDK enabled so it's mostly skipping the whole kernel. >>=20 >>=20 >>=20 >> 2016-04-28 11:50 GMT-03:00 Alan Somers : >>=20 >>> On Wed, Apr 27, 2016 at 1:21 PM, Z=C3=A9 Claudio Pastore = >>> wrote: >>>=20 >>>> Hello everyone, >>>>=20 >>>> I would like to hear your suggestion regarding the best approach to >>>> process >>>> IP packets for filtering, in such a way I can avoid lowering my pps = rate. >>>>=20 >>>> Today a have a simple application proxies http application. It's = dual >>>> threaded on a 4 core system with low CPU power. The current = application >>>> uses two threads, one for control and one for data flow processing. >>>>=20 >>>> I need to implement a simple set of stateless filtering, I will = process >>>> only: >>>>=20 >>>> - src-ip >>>> - dst-ip >>>> - src-port >>>> - dst-port >>>> - iplen >>>> - proto (tcp/udp/other) >>>>=20 >>>> My current rate of requests per second is high, around 200K. I have = no >>>> idea >>>> how I can leverage the IDLE CPUs the best way to implement this ACL >>>> filtering trying not to impact on the pps rate I have today. >>>>=20 >>>> I have implemented it serial today (not threaded) and I get 40% >>>> performance >>>> loss. I will handle max 128 filter rules, this is a decision which = is >>>> made. >>>> This is going to be first match wins. >>>>=20 >>>> My current plans are to test: >>>>=20 >>>> 1) Create 6 threads, one to test each aspect of the ACL (src-ip, = dst-ip, >>>> etc) the first thread that returns false to parent thread I stop >>>> processing >>>> that rule and go to the next, and tell all other threads to = die/exit >>>> since >>>> they don't matter anymore. >>>>=20 >>>> 2) Create one thread to process a batch of rules, say, 8 rules per = thread >>>> per request. Don't know if I would limit total number of threads = and lock >>>> requests while threads ar e busy. >>>>=20 >>>> 3) Someone suggested "do as pf/ipfw do" but I have no idea how it's = done, >>>> how multithreaded it is and what is done on each thread. >>>>=20 >>>> 4) Other suggestion? >>>>=20 >>>> This is going to run FreeBSD 11, I use libevent2 on the current >>>> application >>>> so far. >>>>=20 >>>> Thanks. >>>> _______________________________________________ >>>>=20 >>>>=20 >>> Is there some reason why you can't simply use pf or ipfw? ipfw can = do >>> everything you described. pf can do most of it, but I'm not sure if = pf can >>> filter on iplen. If I were you, I wouldn't attempt to write my own >>> userland firewall until I was absolutely sure that neither pf nor = ipfw >>> would work. If that's the case, then I would try using diverter = sockets. >>> With a diverter socket, pf or ipfw does most of the work, but when = it >>> encounters a packet it can't process it pushes it up to a userland = helper. >>> The userland helper processes the packet and then tells pf or ipfw = what to >>> do with it. In realistic applications, pf or ipfw also creates a = temporary >>> rule based on the userland helper's decision. Applying the = temporary rule >>> in the future is far faster than invoking the userland helper. = After a >>> certain amount of time, the temporary rule will expire again. >>>=20 >>>=20 >>> Here's an example in action: >>> http://daemonforums.org/showthread.php?t=3D8846 >>>=20 >>> -Alan >>>=20 >>=20 >>=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Thu Apr 28 21:21:07 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9100FB201FE for ; Thu, 28 Apr 2016 21:21:07 +0000 (UTC) (envelope-from zclaudio@bsd.com.br) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4864F19E1 for ; Thu, 28 Apr 2016 21:21:07 +0000 (UTC) (envelope-from zclaudio@bsd.com.br) Received: by mail-wm0-x232.google.com with SMTP id e201so4939919wme.0 for ; Thu, 28 Apr 2016 14:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=fSCDUzKPw5QfabQlAciNdoUdloFC6Auqx2f4fT9u478=; b=M0zIgCogFTDa4hdVPBiVgBTDnVzTtWNU+OyAcKXQCVfCIf+fFlpz+oZ+i2+31g8VNG lx8FCACYLKnD7wFn+gV8dojctK5wfx/JYwWgH4+dVkBR8MQC5D0AcnsZVg2WC74PORdc 47WHERS3KN7MYAcDfu+ZTFhvtULRX+uzD5rCQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=fSCDUzKPw5QfabQlAciNdoUdloFC6Auqx2f4fT9u478=; b=kZg6nnTA3aLlRxeA/HTuxcD3DSsqavHEKAgy6RPB9sMh0JcgDzFwY+qn+Gc3V4MckK a1OjkbiQEQHlCRYzkXyKXLl8H3/WlEzoWj9AAPlItzDRMHQQMrcyl+EUj3VqRlkzOs4/ Po2r7X79Ftx4auDZ3E85lHuV5PCEOZ/fC7UrZ+PNbzT69UoBU9ZPoPSfkayatS3j0rLU 7oOSsRFJ1/G2AO0gdSct5Yq+CRo5uSUdelbPyqUU0wjTi8zXMk6XuvBXZ497Q32HYOTA U5oG/xBH4GaPify7UvHYETYMkkv3bILMzJGOS+b6C1mkMg8EgetNYuGzUZHCY8RLVT70 Np4A== X-Gm-Message-State: AOPr4FXSdrZmsSFDxz14+IdmSbpE+q/pm8esImVRsfYH/1fxXQji+b2n+SuTds4O3YyIhNuAF6KXr0quw01jFg== MIME-Version: 1.0 X-Received: by 10.194.2.130 with SMTP id 2mr17710379wju.77.1461878465150; Thu, 28 Apr 2016 14:21:05 -0700 (PDT) Received: by 10.28.183.131 with HTTP; Thu, 28 Apr 2016 14:21:05 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 Apr 2016 18:21:05 -0300 Message-ID: Subject: Re: Best option to process packet ACL From: Ze Claudio Pastore To: Alan Somers Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 21:21:07 -0000 2016-04-28 14:46 GMT-03:00 Jim Thompson : > > If your application is already using DPDK then: > > 1) it=E2=80=99s not =E2=80=9Cmostly bypassing the kernel=E2=80=9D, it *is= * bypassing the kernel. > > 2) ACLs are already a thing in DPDK: > http://dpdk.org/doc/guides/prog_guide/packet_classif_access_ctrl.html > > 200Kpps is not a lot of load for even =E2=80=98pf=E2=80=99 on slow hardwa= re. > > > On Apr 28, 2016, at 12:35 PM, Alan Somers wrote: > > > > Even if your application is not a traditional firewall, using pf or ipf= w > > would save much development time compared to writing your own packet > > filter. They can be configured to do things like redirect packets to > > different ports. You can use that to offload packet filtering from you= r > > application to the firewall, and open multiple sockets in your > application > > to receive prefiltered packets. > > > > Of course, pf/ipfw can't be used in combination with DPDK, as you > > discovered. Doesn't DPDK provide access to each queue of a multiqueue > > NIC? If so, you can create multiple filtering threads, and associate > each > > thread to a single queue of your NIC. > > > > Good luck, you've got a lot of work ahead of you. > ok, again, it's not a L3/L4 ACL, I am looking into L3/L4 information but on a request basis not per packet, depending on other previous criteria I will them split the processing, I am running a proxy so I am not looking to replace my ACL needs by something else, only want to discuss how to better process it, I have previous information from L7 affinity, headers, request which helps me split some load, now I happen to need to filter it, it's not a firewall, it's much like a squid based ACL need where you look for L3 info on a different moment, ipfw/pf won't do it for me, ordinary firewall fits somethwere else in the topology not in this application. back on focus, I need to understand how to better split this load among IDLE CPUs From owner-freebsd-hackers@freebsd.org Fri Apr 29 15:34:45 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1846AB20E23 for ; Fri, 29 Apr 2016 15:34:45 +0000 (UTC) (envelope-from dennix.pearson@gmail.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D44F21C95; Fri, 29 Apr 2016 15:34:44 +0000 (UTC) (envelope-from dennix.pearson@gmail.com) Received: by mail-io0-x22d.google.com with SMTP id 190so105562205iow.1; Fri, 29 Apr 2016 08:34:44 -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; bh=4MIV9OD6zQPVL7NrC0pUUkIpvk/aWqgoLKKRwJkjepE=; b=Ie77m8Vmc/2fELW0CKhN3sCJH2S97txf7oNUoPNi602QvnttNVSHjF6Y9CqLfV1q2k VBP7uJY8xDWd9OGbml1igH0A/vOFUL7AmadQnx518Pjt5jpwWKmjveTNspiRFiqK+TSZ lnxjD5lJiTcARJGZmr+4u4uou2kuz1JeckWVioe5j1+U3fUfViP+NTBUGKIKQj3MPHsJ z+MPICz6k+PnjfA0wXt5LGQrt4GWfH3fJqJVfBNAKWPxX7hlIXvonDbSRvNGKPb0uGpw G2YXVeIC5D1YhP4WO8Yq4MsLoBvQw5eYO0pbj9WDw+TfTil+A0ccYJJOshHOCDJQBgb7 rhkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=4MIV9OD6zQPVL7NrC0pUUkIpvk/aWqgoLKKRwJkjepE=; b=ZcvfgzYAzIzY/8D9vE4dWCZ7FE+g5GaKwtKlLJAXWEQe109FTK+pNumJW2NGz2sZrc d1jR802CZ/bTvsuMIAK60gk7y6D3iquFl9gCbjy1eMcsRMJr4xbtelPl4Wt/MNd+FV1c 0nmr0da2uwe2p+kHC4tqGoWb/QduL/ln6veeQBwMePC1omX3OUEVZZGTLyMJGr/G137w S2R2RUtkkOlN9VeWFQ08Oqm9/aTKjkmwPbvffF8GxkFPbTUuVzMQYGQOov1yMkCDh1ar AA45I2ZPMDK7NZH+Wm7Y6fX/h8mk/uzuy/Z1QhLTs3sMq+ktS4yY5xgL/MlS1N4lHbtg sw6w== X-Gm-Message-State: AOPr4FU4Rpti+ibeYcQJWOypyGOv/hCTlT8ZIQBGWXRIbWmYjRQJr+I+cpI0+gYF+9myyzVjz9AJ8Wpq2vBOQA== MIME-Version: 1.0 X-Received: by 10.107.143.76 with SMTP id r73mr25358014iod.54.1461944084204; Fri, 29 Apr 2016 08:34:44 -0700 (PDT) Received: by 10.79.4.88 with HTTP; Fri, 29 Apr 2016 08:34:44 -0700 (PDT) In-Reply-To: References: Date: Fri, 29 Apr 2016 12:34:44 -0300 Message-ID: Subject: Re: Best option to process packet ACL From: Denis Pearson To: Ze Claudio Pastore Cc: Alan Somers , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 15:34:45 -0000 On Thu, Apr 28, 2016 at 2:20 PM, Ze Claudio Pastore > wrote: > Because actually, this is ot a packet firewall. > > When I mentioned pf/ipfw is only to reffer to ideas on how to best match > each acl criteria. > > But my userland application is a proxy, ACL will handle L7 requests withi= n > the packets. I will filter based on the mentioned criteria but it will be > processed at a different moment unrelated to packet in kernel. It's also > DPDK enabled so it's mostly skipping the whole kernel. > AFAIK, you are on your own. Both PF, IPFW and Iptables/NETFILTER if I am not wrong are essentially monothread. Except that each packet is usually processed by kernel leveraging on interrupt triggering, which might in this case be multithreaded, but the efficiency depends on how the kernel balance interrupt on SMP systems which on it's hand, depends on each interface vendor and driver. For example, adaptive interrupt, etc. Each vendor and NIC does this differently and advantage from multithreaded drivers *might* benefit firewalling indirectlly, but the firewall code is in fact monothread. If I recall well, pf does a couple things multithread on FreeBSD, like state processing, purge, loading flushing and something pfsync related, while ipfw does table radix processing (some sort of) and dummynet enqueuing. Everything else is leverage on how interruption is distributed on the system. So a general algo for YouTube ACL would first look into information which won't match (match has less probability). You are looking for a FALSE here, the first FALSE you get and the sooner you get it, better, you skip that rule and try to match the next one. More common rules should be tested first since you mentioned first match wins. I would first evaluate src-ip (32bits/128bits or a CIDR to test), src-port after that, dst-ip and dst-port after that, finally packet len and proto. Criterias unset on each rule must be skipped (never tested since they will always return TRUE). Remember to add a counter to help the user see the more common rules and try to move it to the top of the list. For threads I would have each packet evaluated in a different thread but all test criterias tested in the same thread, and limit the number of threads. Set a common default based on the hw.ncpu, let the user tune it as it's done on nginx/apache (threaded workers)/suricata for example. You said it's not a packet but a request, I am assuming testing criterias would take some time not to let it serial. But you have a tradeoff to measure first, how long it takes to create a thread, join it, in nanoseconds? I can't tell, and how long it will take for you to test all your criterias in serie? Because you will be spawning threads up to N threads which might be (NCPU*N)=3DX and therefore it will cost Xns time on the parent thread to spawn and get response from children. The tradeoff must be good when comparing to serial testing. Some people also prefer to split RX and TX in different threads, this is how ACL is processed on vRouter for example and I believe this is how Luigi Rizzo did it on tlem.c if I remember well. I don't know if you have different criterias for IN vs OUT acl requests, if you do, splitting this horizon would be something else to investigante. I think one thread per test criteria is difficult to manage and possibly costy (several instructions to manage it). One thread per batch of rules looks better, while my suggestion is to have one thread per packet testing all criteria on all rules. I am sure you have to investigate the tradeoff. Finally, can't you simply have multiple (but fewer) threads of your application as a whole, leveraging on all CPUs and balacing the load among 'em? So if you have 4 CPU you will have 4 main working threads (and maybe one extra control thread to balance and handle the load distribution, signal, configurations, etc), and you would implement ACL evaluation criterias in series instead of multithread. Because I am really afraid of your cost to spawn/join/manage such a huge amount of threads. Doesn't matter if it's 200Kpps, 10Kpps, 1Kpps, it's still a LOT of pps to handle in different threads IMHO (since it's potentially ((packets*(test_criteria*num_rules))/second). And maybe you will need to use mutex locks, semaphores or events since you will limit the number of threads and therefore at some time your parent thread will say "hey, hold on, let's wait for some slots to free" for Packers arriving on a quepe before ACL evaluation. > > > > 2016-04-28 11:50 GMT-03:00 Alan Somers >: > > > On Wed, Apr 27, 2016 at 1:21 PM, Z=C3=A9 Claudio Pastore > > > wrote: > > > >> Hello everyone, > >> > >> I would like to hear your suggestion regarding the best approach to > >> process > >> IP packets for filtering, in such a way I can avoid lowering my pps > rate. > >> > >> Today a have a simple application proxies http application. It's dual > >> threaded on a 4 core system with low CPU power. The current applicatio= n > >> uses two threads, one for control and one for data flow processing. > >> > >> I need to implement a simple set of stateless filtering, I will proces= s > >> only: > >> > >> - src-ip > >> - dst-ip > >> - src-port > >> - dst-port > >> - iplen > >> - proto (tcp/udp/other) > >> > >> My current rate of requests per second is high, around 200K. I have no > >> idea > >> how I can leverage the IDLE CPUs the best way to implement this ACL > >> filtering trying not to impact on the pps rate I have today. > >> > >> I have implemented it serial today (not threaded) and I get 40% > >> performance > >> loss. I will handle max 128 filter rules, this is a decision which is > >> made. > >> This is going to be first match wins. > >> > >> My current plans are to test: > >> > >> 1) Create 6 threads, one to test each aspect of the ACL (src-ip, dst-i= p, > >> etc) the first thread that returns false to parent thread I stop > >> processing > >> that rule and go to the next, and tell all other threads to die/exit > since > >> they don't matter anymore. > >> > >> 2) Create one thread to process a batch of rules, say, 8 rules per > thread > >> per request. Don't know if I would limit total number of threads and > lock > >> requests while threads ar e busy. > >> > >> 3) Someone suggested "do as pf/ipfw do" but I have no idea how it's > done, > >> how multithreaded it is and what is done on each thread. > >> > >> 4) Other suggestion? > >> > >> This is going to run FreeBSD 11, I use libevent2 on the current > >> application > >> so far. > >> > >> Thanks. > >> _______________________________________________ > >> > >> > > Is there some reason why you can't simply use pf or ipfw? ipfw can do > > everything you described. pf can do most of it, but I'm not sure if pf > can > > filter on iplen. If I were you, I wouldn't attempt to write my own > > userland firewall until I was absolutely sure that neither pf nor ipfw > > would work. If that's the case, then I would try using diverter socket= s. > > With a diverter socket, pf or ipfw does most of the work, but when it > > encounters a packet it can't process it pushes it up to a userland > helper. > > The userland helper processes the packet and then tells pf or ipfw what > to > > do with it. In realistic applications, pf or ipfw also creates a > temporary > > rule based on the userland helper's decision. Applying the temporary > rule > > in the future is far faster than invoking the userland helper. After a > > certain amount of time, the temporary rule will expire again. > > > > > > Here's an example in action: > > http://daemonforums.org/showthread.php?t=3D8846 > > > > -Alan > > > _______________________________________________ > freebsd-hackers@freebsd.org > mailing lis= t > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org > = " >