From nobody Fri Mar 31 00:15:27 2023 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PngmQ46fwz42Zb4; Fri, 31 Mar 2023 00:15:34 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PngmQ3Lmtz3GqG; Fri, 31 Mar 2023 00:15:34 +0000 (UTC) (envelope-from kp@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1680221734; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=b85aFZWbnVPK7nmIx64kWKso7AJH+qDqaAckbJi17no=; b=tyOAonBk+eo0tNOWiNaVInyNh/s01c7JoCCOOOpjsvSg/b1oLz+203GjnNumIIzYkSjfOM QYkL5/fjqCEjyOAAu9l5YtIw9lLshKCdtmOgj14IdCav03AkFsheFh9Sgv+mIIXYeBmKAr fuzCv1R4mJEmGpALxFXWgLyELy5XXjNAQ0Ptpxk6dnYFgGZWTEhMQ70k826uJnxI8Wh45Z oZd3tcvLkf6rQkyxDurJpVJqjcyUNKsEyLhZ3WADAncP6d/IkOGqFHLbIKVfxEvpwq1Wjq W1jDu4sZPXqaxtTQ7fMOe9wvhF75K7M3tMgpi4swtU/IIrsxssUJqJLzvO2F0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1680221734; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=b85aFZWbnVPK7nmIx64kWKso7AJH+qDqaAckbJi17no=; b=yn5km3i/0c6kzYN03kmWlpchZEFPySrvI52PvX2t976jR2Hf5kWaPGOvZWanRPrXydfAU0 +CNzR1nvu0fJIDd2vrDOABHRnQEKUrIc4MSx++vLsFXXFtnnSlYpHJQW82pR3SPQG0k/qa i20WnOQLO8MZ8aykaDE7Mm7kLJF++Y8IpUAB5U9oJ84GQbJ5UON1VGLzeXz5wuIhREPIk4 qrfCdTlpRRWXbrgVW/0wlKP8Zt8atOOpoPyPgvyTi63GD8QvUYrBQ1V+KRAV3K1V4TdZzC USBGUNHX5UAv+NuSbNOUwXTwRnnp2ix+OaD/n4/I6R6W2bxhYgM3w+Gs8YQ2UA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1680221734; a=rsa-sha256; cv=none; b=woDmu/lx8TQUI5ed5YqXaoj5GSJVlPYnb7aMWzW+neFhToxqbWPhPNEL4ul+77amP1aaKn Kx+KEBSawRQeoQw1ZQsskrOvrjrFRXzs1EyDClCX+i7swFnW4l2Gv+cKw/CmtF5MhGpgaD UrYk3shjRib2upbBHdGAaFUl1DKLv5+9MdB+9Jm1SRQ/WixUvhvVFTdgpYxzfaN98laz8N bJaIbwaX7rkA6iQngZ05nqexeQst3zg/e0HVNCk9qUJYUbgAP+3kmOANJ2AEISJ2mT4PVO IbjGIpnA0IU+B7Bby7JCvc8GsrnX9ANsmdYjj8rqo1g/1c/Y1QJgYAWVbg9sHQ== Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx1.codepro.be", Issuer "R3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PngmQ1hs0znKc; Fri, 31 Mar 2023 00:15:34 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id 636F0CD04; Fri, 31 Mar 2023 02:15:31 +0200 (CEST) From: Kristof Provost To: Mark Johnston Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: b60600ceeb68 - main - pf tests: Serialize Date: Fri, 31 Mar 2023 09:15:27 +0900 X-Mailer: MailMate (1.14r5937) Message-ID: In-Reply-To: References: <202303302336.32UNatba067594@gitrepo.freebsd.org> <3A26AB82-357F-421F-853E-07320387ACBE@FreeBSD.org> List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-ThisMailContainsUnwantedMimeParts: N On 31 Mar 2023, at 9:05, Mark Johnston wrote: > On Fri, Mar 31, 2023 at 08:56:56AM +0900, Kristof Provost wrote: >> On 31 Mar 2023, at 8:36, Mark Johnston wrote: >>> The branch main has been updated by markj: >>> >>> URL: https://cgit.FreeBSD.org/src/commit/?id=3Db60600ceeb68d1001d6122= 2830e0be3441ef0885 >>> >>> commit b60600ceeb68d1001d61222830e0be3441ef0885 >>> Author: Mark Johnston >>> AuthorDate: 2023-03-25 12:55:41 +0000 >>> Commit: Mark Johnston >>> CommitDate: 2023-03-30 23:35:59 +0000 >>> >>> pf tests: Serialize >>> >>> These tests reuse jail names and cannot run in parallel. Until t= his is >>> fixed - which is desirable since these takes take a while to run = - tell >>> kyua to serialize them. >>> >> >> The tests also recycle IP ranges, so merely changing the jail names is= insufficient. > > Could you please give an example? I looked at some of the tests but ca= n > only see cases where addresses are assigned within the vnet jail(s) > created by the tests, in which case I'd expect no problems. > Altq:hfsq assigns 192.0.2.1/24 on an epair on the host, so does altq:matc= h, altq:cbq_vlan, altq:codel_bridge, dup:dup_to, ether:mac, ether:proto a= nd .. then I got bored looking. It=E2=80=99s not just the pf tests either. For example the netinet/forwar= d:fwd_ip_icmp_iface_fast_success test does that too (well, 192.0.2.1/29, = but anyway). There are going to be more, this is just from a very quick l= ook. >> Realistically the easiest way to get these to run in parallel would be= to run each test in its own vnet so both overlapping IP ranges and name = conflicts don=E2=80=99t matter. > > Yeah, I was wondering whether it'd be possible to have kyua handle the > creation and teardown of a per-test jail, if only to avoid having to go= > through all of the tests which use static jail names. That=E2=80=99s what I was thinking as well, yes. We might be able to get to a point where all the tests have unique jail n= ames, but we=E2=80=99re never going to manage to de-conflict all of the I= P assignments. Even if we could, it=E2=80=99d make writing tests harder a= nd that=E2=80=99s counterproductive. The only issue I can think of with having the tests run in their own vnet= is that there may be some tests that play with non-vneted sysctls, so we= will have to make that vnet feature optional. Best regards, Kristof