Date: Thu, 16 Jan 2020 21:27:28 +0100 From: "Kristof Provost" <kp@FreeBSD.org> To: "=?utf-8?b?0JDQu9C10LrRgdC10Lkg0J/RgNC+0LrQvtC/0YfRg9C6?=" <alexpro.ewr@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Porting pf from current OpenBSD to FreeBSD Message-ID: <D723E39E-5A78-4F66-AAAA-35280B4F927C@FreeBSD.org> In-Reply-To: <8f975ad7-e326-1472-e8e0-88cf69dd9131@gmail.com> References: <8f975ad7-e326-1472-e8e0-88cf69dd9131@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16 Jan 2020, at 16:25, Алексей Прокопчук wrote: > Now I'm trying to port the current pf from OpenBSD to current FreeBSD. > As a separate module this time, without any changes in the FreeBSD > kernel code. > That’s one of the better ways of trying to update our pf, yes. I wrote a more extensive e-mail about this a while ago (https://lists.freebsd.org/pipermail/freebsd-pf/2019-April/009094.html), but briefly, there are three main areas of concern for a pf update. - performance: OpenBSD’s version is still limited to running on one core at a time. - vnet: OpenBSD has no direct equivalent - syntax differences would break existing rulesets The last one of those is not a concern for your project right now. VNET support is also optional, and all in all relatively straightforward to add afterwards. The performance aspect of it isI’d worry about that only once you’ve gotten an OpenBSD pf working though. Many users will be satisfied with the performance of OpenBSD’s version. When we’ve vaguely discussed this the suggestion was to treat this as a port, rather than as something that’d go into the base system. (We don’t want to add a fourth firewall, after all!). Still, that doesn’t affect this project too much. > There are quite lot of inconsistencies - counters, tasks, crypto, > routing domains, mbuf, inpcb and others. > In your opinion, what is the best way to solve the inconsistencies > with the current kernel? > That is an excellent question I do not have an immediate answer to. > In case of inpcb I've created a structure containing the inpcb itself > and additional members, which are OpenBSD - specific. My recollection is that we really only need the inpcb for the user matching code. For a first version you might be able to get away with just disabling that feature. In any case, I don’t expect we use many fields from the inpcb. > In case of routing domains I've decided to always use the default > value 0 and make a function stub rtable_l2(), which returns 0 in all > cases. A good initial shortcut. I’m not familiar enough with rtables to say for sure, but aren’t they somewhat comparable to our fibs? > In case of the tasks I intend to use tasqueue "swi" for the enqueue > task. > Yeah, that’s what the FreeBSD pf version does too. > I have almost no experience in the development of the FreeBSD kernel, > perhaps you could give me the cue as to where I'm making mistakes. > Do you have an in-progress tree somewhere? Best regards, Kristof From owner-freebsd-hackers@freebsd.org Fri Jan 17 15:40:23 2020 Return-Path: <owner-freebsd-hackers@freebsd.org> Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 095E01F1960; Fri, 17 Jan 2020 15:40:23 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f41.google.com (mail-io1-f41.google.com [209.85.166.41]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47zld21mDkz4d17; Fri, 17 Jan 2020 15:40:22 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f41.google.com with SMTP id i7so18024582ioo.5; Fri, 17 Jan 2020 07:40:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=mQN3BExkO/1ZNExpcGCUnU83Vh6dKx/hUkcXHSp0Fzs=; b=rTL8onmsL0hI+rgV8sHD1kf8ZdAmHiUizEIdoszBl/Bhc8W1ZJgz0hweLq6GuLm1jx jL085kusOZLOAWEmxtezhL9eQDUF3fwTkuXq8oZxhAngcs8z2WaovHNhCIe2ZKx/J+UQ +e+Bq1AKJfxbFnyB5I+RsYteWchmaHz7HsmYGFIMVCF6ukemHm5aKZZrgnpDybTaEM/Q V80Yt7pnXrb9r9xrqWuZfkIuVm8zs/H8gIYI+V8GAF2qjzVYpaWaqjVlfPs8Vvkg4JUP gXPnMTZUenIWeT2Wm+3PJ6VxvKhQmPE7Vcw2+ehdY5V/LNo4s92HpB35BPBBNxDwZRaS RNaw== X-Gm-Message-State: APjAAAWRw4+trMs8HtkKZK1sAB+ivhbZcunGkROa8UJlwaWyH2QfsaGr rpU/RA/gCVM8ZdKgKgI7yHX5CK9L2LsLReW7jybMOpQt X-Google-Smtp-Source: APXvYqw18kUc/t61h0p6F0i/IyU+HAm1IV2AZSCiKk8a6rSPWFltMhLNR8WUMVWH3tm2ZvZM2wqkXyN248JYSzUfpGE= X-Received: by 2002:a6b:db12:: with SMTP id t18mr29332815ioc.11.1579275620639; Fri, 17 Jan 2020 07:40:20 -0800 (PST) MIME-Version: 1.0 From: Ed Maste <emaste@freebsd.org> Date: Fri, 17 Jan 2020 10:40:09 -0500 Message-ID: <CAPyFy2Bk6DTYrDgkhra9xP03bJZXq5vDkD8iXbTZZGpfj3MUZA@mail.gmail.com> Subject: Turn off PROFILE option and remove WITH_PROFILE after FreeBSD 13? To: FreeBSD Current <freebsd-current@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 47zld21mDkz4d17 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.41 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-2.79 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-1.79)[ip: (-4.01), ipnet: 209.85.128.0/17(-3.07), asn: 15169(-1.83), country: US(-0.05)]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[41.166.85.209.list.dnswl.org : 127.0.5.0]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[41.166.85.209.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD <freebsd-hackers.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-hackers>, <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers/>; List-Post: <mailto:freebsd-hackers@freebsd.org> List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe> X-List-Received-Date: Fri, 17 Jan 2020 15:40:23 -0000 As far as I can tell most/all developers have used sampling-based profiling for years (e.g. hwpmc on FreeBSD) and have not been using gprof-based profiling. Prompted by followup to a pkgbase tweak I committed relating to profiling libraries[1] I propose following Brooks' suggestion: * turn off the PROFILE option by default now, in advance of the FreeBSD 13 branch (WITH_PROFILE will remain available) * update the WITH_PROFILE description in src.conf(5) to mention that it's deprecated * remove support for WITH_PROFILE after FreeBSD 13 branches Any comments on this plan? Does anyone use the -pg compiler flag and the _p.a profiling library archives? [1] https://lists.freebsd.org/pipermail/svn-src-all/2020-January/192566.html
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D723E39E-5A78-4F66-AAAA-35280B4F927C>