From nobody Tue Mar 26 18:31:48 2024 X-Original-To: freebsd-net@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 4V3z0z1XJvz5FYq5 for ; Tue, 26 Mar 2024 18:32:03 +0000 (UTC) (envelope-from benoitc@enki-multimedia.eu) Received: from mail-4022.proton.ch (mail-4022.proton.ch [185.70.40.22]) (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 "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V3z0x0W68z5772 for ; Tue, 26 Mar 2024 18:32:00 +0000 (UTC) (envelope-from benoitc@enki-multimedia.eu) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=enki-multimedia.eu header.s=protonmail2 header.b=lCz+XD2A; dmarc=pass (policy=none) header.from=enki-multimedia.eu; spf=pass (mx1.freebsd.org: domain of benoitc@enki-multimedia.eu designates 185.70.40.22 as permitted sender) smtp.mailfrom=benoitc@enki-multimedia.eu DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enki-multimedia.eu; s=protonmail2; t=1711477917; x=1711737117; bh=qV8eE4xIenBshEIBnOKJcszbA9MxLYbScQ9+c+I8ytY=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=lCz+XD2AbxwpfQV/yTVfmzn0O1ZHcxycGSvV2QtqOdNgNj9R1NBRi+fAf9bOuAClB 1yGSbmwHCCIvtH8ySHrdNxb80eR9Do1h7OKjeJz9C4JkaZ2x8lRss9MnZztk4yo1Ad E6OEVBej/Z67tw//1/bBrwd/fHcThbie/vF/5yP6krvTdHQcsJRq5eIXFZvvtT+wxX xuJgP6Y1/UdwqnqEdV02pfH/VgY2JOMYdf5ubEDuFVlaItg1uJ4RZfcmnQW2hnwTVP iKJO3HeMbuIZpgvydmebg2qu15P4pVdG+zi9OQcEtzjUfLSBol1BkPS3IUiVYoPCfn HwOqfoGP2cWHA== Date: Tue, 26 Mar 2024 18:31:48 +0000 To: "freebsd-net@FreeBSD.org" From: Benoit Chesneau Subject: vnet with interfaces Message-ID: Feedback-ID: 9066678:user:proton List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_nzfho3v8fmm1f5HU6kAQ9xNFptYvGVIA8mcrMTiz0" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.09 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.992]; DMARC_POLICY_ALLOW(-0.50)[enki-multimedia.eu,none]; RWL_MAILSPIKE_VERYGOOD(-0.20)[185.70.40.22:from]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; R_DKIM_ALLOW(-0.20)[enki-multimedia.eu:s=protonmail2]; MIME_BASE64_TEXT(0.10)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCPT_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_ZERO(0.00)[0]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_PHPMAILER_SIG(0.00)[]; DKIM_TRACE(0.00)[enki-multimedia.eu:+] X-Rspamd-Queue-Id: 4V3z0x0W68z5772 This is a multi-part message in MIME format. --b1_nzfho3v8fmm1f5HU6kAQ9xNFptYvGVIA8mcrMTiz0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SG93IGRvZXMgd29yayBWTkVUIHdpdGggaW50ZXJmYWNlcz8gSXMgdGhpcyBhcyBlZmZpY2llbnQg YXMgdXNpbmcgcGNpIHBhc3N0cm91Z2ggaW4gYSB2bSA/CgpCZW5vw650 --b1_nzfho3v8fmm1f5HU6kAQ9xNFptYvGVIA8mcrMTiz0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij5Ib3cgZG9lcyB3b3JrIFZORVQgd2l0aCBpbnRlcmZhY2VzPyBJcyB0aGlzIGFzIGVmZmlj aWVudCBhcyB1c2luZyBwY2kgcGFzc3Ryb3VnaCBpbiBhIHZtID8mbmJzcDs8L2Rpdj48ZGl2IHN0 eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPjxi cj48L2Rpdj4NCjxkaXYgY2xhc3M9InByb3Rvbm1haWxfc2lnbmF0dXJlX2Jsb2NrIiBzdHlsZT0i Zm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCiAgICA8 ZGl2IGNsYXNzPSJwcm90b25tYWlsX3NpZ25hdHVyZV9ibG9jay11c2VyIj4NCiAgICAgICAgPGRp diBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IHRleHQtZGVjb3JhdGlvbjog bm9uZTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBjb2xvcjogcmdi KDAsIDAsIDApOyI+QmVub8OudCZuYnNwOzwvZGl2PjwvZGl2Pg0KPC9kaXY+DQo= --b1_nzfho3v8fmm1f5HU6kAQ9xNFptYvGVIA8mcrMTiz0-- From nobody Tue Mar 26 19:30:00 2024 X-Original-To: freebsd-net@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 4V40J81v0Pz5Ffmq for ; Tue, 26 Mar 2024 19:30:16 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com [IPv6:2607:f8b0:4864:20::1134]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V40J8092Xz41n3 for ; Tue, 26 Mar 2024 19:30:15 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-609fc742044so63203207b3.1 for ; Tue, 26 Mar 2024 12:30:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1711481413; x=1712086213; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=RO1qmfauKzQJFpT7CmUfkUE3u+ofZur6sUeYfuiD2+8=; b=bAcNTx9zMVV53i6jk+dgqUQn4ktH+YfRxcYUijY8Q6Lwadgs7OCiaTzH02/Q8NJt2a 2FoW5WLkyAMN6LI85LMjuXU78dRcji+5DjCeTOGN8Pz+5FyicZWeegLiQyFsu+k3pt0C fuirfVnj+NPkFDU69Iny+OAhdHc1wlzB76bOx4QC8LzCzX0eP+qMv2bKo1+/kTQxiNJ7 kagtyuYLTflmIDaWU2Ohbp7x2f+Evz6AZONYpk76HRQiC8262ziH+3Letg8PBH//UJbh krdjwauLD5vRUGAIS/Tq8JbgCYO1upYpFW0rOm0ttyihZ5Drl51FKsvfV0QQQCMip3ib Arzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711481413; x=1712086213; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=RO1qmfauKzQJFpT7CmUfkUE3u+ofZur6sUeYfuiD2+8=; b=rO5wh5D5HSUfnmO86zHOTil34riGR5fkL7DGc19htEiG7g2FMdmimo9b/m+Hna0A9C a/xDVZi+JpL1Cq0Xryr5AhY9T1m3FLyaOY6Wnu5QRRiYTy1VsQTnzijKMsh6eHalvKqu 0oLo7nHqeaikROZXM6lgpYVnKGF8nWnx7LKsx/jj21Si/VSAMJSQuzE8Q0U8PK/12TIF gCZbO0XSC5BDFP1R3BhR7OorIij5FG2/OC5VdRrlRublDiNwSl/gB35bKlk03HCLIc3h VBw2iIrbDYel4qpoFBCb3iJiTAbXb0fJ4VmOasYlVLvTeVj0doGQ3dIKF0etWDXiPtWV Xh9w== X-Gm-Message-State: AOJu0YxDT1rXIsVRzXtChtrXYJl6cZbx7daT2eo3ikKsMUa0tTG58ufw sa1C3Sn90ofyreqAN91PeQiFDstVaBg+FAzCgwHaP29jTaFyPezkXUSl25IIaqVlmWbGyjM19To = X-Google-Smtp-Source: AGHT+IGG7pOiPOWYit+8o80h/gMi3v0YGADm5ipCpztYZVKyAjkkZ6qH4OXV/qzC3vv2sbMja1zKeQ== X-Received: by 2002:a81:6d09:0:b0:611:22a:3dea with SMTP id i9-20020a816d09000000b00611022a3deamr658844ywc.17.1711481413132; Tue, 26 Mar 2024 12:30:13 -0700 (PDT) Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com. [209.85.219.170]) by smtp.gmail.com with ESMTPSA id g184-20020a8152c1000000b0060a304ca3f4sm1618798ywb.19.2024.03.26.12.30.12 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 Mar 2024 12:30:12 -0700 (PDT) Received: by mail-yb1-f170.google.com with SMTP id 3f1490d57ef6-dd10ebcd702so6065895276.2 for ; Tue, 26 Mar 2024 12:30:12 -0700 (PDT) X-Received: by 2002:a25:c706:0:b0:dd1:7908:3a49 with SMTP id w6-20020a25c706000000b00dd179083a49mr639780ybe.23.1711481411937; Tue, 26 Mar 2024 12:30:11 -0700 (PDT) List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Tomek CEDRO Date: Tue, 26 Mar 2024 20:30:00 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: vnet with interfaces To: Benoit Chesneau Cc: "freebsd-net@FreeBSD.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4V40J8092Xz41n3 On Tue, Mar 26, 2024 at 7:32=E2=80=AFPM Benoit Chesneau wrote: > How does work VNET with interfaces? Is this as efficient as using pci pas= strough in a vm ? > Beno=C3=AEt Vnet allows you to control networks by the system and make various configurations networks jails etc, example here: https://klarasystems.com/articles/virtualize-your-network-on-freebsd-with-v= net/ PCI passthrough would skip all kernel networking and give your vm access to the physical cable attached to a NIC. Note that passthrough needs entry in /boot/loader.conf and disables that device for use in system. I have a dedicated USB 3.0 controller working that way. A very simple and elegant shell management tool to play with bhyve is vm-bh= yve: https://www.freshports.org/sysutils/vm-bhyve/ Have fun :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Wed Mar 27 03:55:22 2024 X-Original-To: net@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 4V4CVz0Xtvz5GMp8 for ; Wed, 27 Mar 2024 03:55:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V4CVy4yXrz4lK5 for ; Wed, 27 Mar 2024 03:55:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1711511722; a=rsa-sha256; cv=none; b=UIl21AK6vFTXuEPDsfbKkdURbzsw4ptPkbFvOk8LTM1ejOBir2w1W3j71waXncF8h4BoEi LczG68rdMEdTpHu/9RR+AVL6yEiPiiamA8kdJkpYA2v8Z0mZ2tJ+5SROIoptIkiMfEuu6u Dg6BWxQiAKzsFPM+diAvd2qJwC/+iwY0/PmJUq1LjCrV+/lx6PTthPGKGWpU3tP5ODc9Po gVypvx++YduBXvQtsT0PO/qdjs65ElVEXNtBOUYdOc5I8obccRksgiTlN12/WOToGJkNJ4 UXQotIcIM4Bk5HrTNVy7F84XQNyXMSeHukAA5NaaL2kYlHiWWI3QzXJbScHaTA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1711511722; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0jl3o1uEJriD6+rMQjL8chyZmO/yAUVB9LSDD/D5+MQ=; b=q+XxcdsBycJ/37imV0pKREPGWRlMOMd9N+gJ24xwqYTlHPKsfX78gV4zF5P2QFT+KTeOkx dT/ZlESybF3qV2P2mI4HIVuOE42/zxmxxEjbvECcaPP8xfmgKyilWSLS9v8rUzy/soYmkj StBvlcGluVcd2Ij9tyxzIyDmAqW79IKY7C+V+fEipwCWQ57NLxWYu4bZ53k83xFLzR2nw8 sg5dbhwRdVgn+OvSPAgrL/vg4IhoqcaEzkCbmKptRztToFlzqCrHt7hJkVLfv1ivU+mNoC cR9fozuz+dsRVGPGz/EyaLRmKu8Gk/acYDph7IddaUW2ZlQjSP1+KFCcHQVw1A== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4V4CVy4ZCczSSM for ; Wed, 27 Mar 2024 03:55:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 42R3tMEc004467 for ; Wed, 27 Mar 2024 03:55:22 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 42R3tMv0004465 for net@FreeBSD.org; Wed, 27 Mar 2024 03:55:22 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 277771] ice driver report I2C error messages of E822 copper LAN ports Date: Wed, 27 Mar 2024 03:55:22 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 14.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: amy.shih@advantech.com.tw X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D277771 --- Comment #1 from amy.shih --- Hi Sir: Is there any update on this issue? Best Regards, Amy Shih Advantech ICVG x86 Software 02-7732-3399 Ext. 1249 --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Thu Mar 28 08:22:42 2024 X-Original-To: net@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 4V4xP10SD8z5FGG1 for ; Thu, 28 Mar 2024 08:22:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V4xP019y0z3yfx for ; Thu, 28 Mar 2024 08:22:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1711614164; a=rsa-sha256; cv=none; b=AQiIZJClSNI0OFHm79i1EfVYKaEY75yOPHMHGIn8NxA7MrMEbH8VOQbndSbq0hz29FsUqC /e3PB7SaUw11qglva+9zNAwUW1Y/OmDpTV6B4v0PNRU8HN7PBlijxN2MXHWW3Ib1kljBhU TGZPZkODodBhvtwonJ5lgMkZcihR9xe8dDDA2W4/AC+usxepSRlcIFwNxORDWKj5mFG3y7 kfKMhjUBHXP6bBm2umT5V504pGqNsykn5X7vvyoDlEzNJBbLXUh9oeutsT9ETFRzJcTqjn U3vfxau9HuD0qRMHWWEFGw4ztQMRKqiYxdoofzRQQfrs8zCV5auUbwHTx7Z+0A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1711614164; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qPtu8CeFvZ1hkN3FIjJfXF2Mq6Rv7HJB7sJC6hoFQhs=; b=ni9cZ6nVmnJHxEF4G/BBpPxGyH5v1Yyt5BQBRwn4NFmtsR92HyY+Zgif7xVbGBCcDSdkyw xBXv+pJX32VteTgOUjLTt4RBkyA3eKIeP7H0wEyypu3IzPwsljAiAQmLsF99LCYc8evVZL BUqSsdOp9gEXSc/uEOSvIJTWM3aQRwabKA44Bb+H62TIS19H6SyZ/ra3IUhtZZ07DLeIOe jX4Gnr5CFrzzEDyrVsgzx+5Zcgq7E1lyWeu7jSQD4+mUTJWiQyno8O/h1iStjQOgF8BOUp P5pKFuuAU/pG0obCUWnL95odoIyJ22gPsmoq8kp3xZr7bQP7tvfDMB2wmF8hAw== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4V4xP00gLhzKpt for ; Thu, 28 Mar 2024 08:22:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 42S8MhYI044225 for ; Thu, 28 Mar 2024 08:22:44 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 42S8MhK4044216 for net@FreeBSD.org; Thu, 28 Mar 2024 08:22:43 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 275225] On ARM64 carp preempt not working as expected Date: Thu, 28 Mar 2024 08:22:42 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 14.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: eimar.koort@tutamail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D275225 --- Comment #4 from ekoort --- So today it did not work as expected.=20 Main went down, secondary took over, main came up and instantly main took o= ver while it (cluster services) should stay on secondary. So it's a mixed results for unknown reason. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Thu Mar 28 09:17:51 2024 X-Original-To: freebsd-net@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 4V4yd065wfz5FMPZ for ; Thu, 28 Mar 2024 09:18:12 +0000 (UTC) (envelope-from thj@freebsd.org) Received: from fhigh1-smtp.messagingengine.com (fhigh1-smtp.messagingengine.com [103.168.172.152]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4V4yd017Pvz4454 for ; Thu, 28 Mar 2024 09:18:12 +0000 (UTC) (envelope-from thj@freebsd.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=U9i74I5b; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=freebsd.org (policy=none); spf=softfail (mx1.freebsd.org: 103.168.172.152 is neither permitted nor denied by domain of thj@freebsd.org) smtp.mailfrom=thj@freebsd.org Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailfhigh.nyi.internal (Postfix) with ESMTP id C25C41140093 for ; Thu, 28 Mar 2024 05:18:11 -0400 (EDT) Received: from imap47 ([10.202.2.97]) by compute3.internal (MEProxy); Thu, 28 Mar 2024 05:18:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1711617491; x=1711703891; bh=+WYnEDM3OJ6SqW1gy7wvm1ZqDspx GLUEgfJ7x7P7hao=; b=U9i74I5bTy3JWzvVnD62AidgkfKuGI3V3IR8d+0C2V3J CVmdXM8/AaFDaApuCkVVQJ4DwokqAfxRosjs3jLD/SRkhFEBiImXGe7PKTJ3GeFi ly6uJS1CNC8LKX7Mg1wTdrXZMAeyBiyrDvg05Uowt3ULHuE+fdSIHJrdzhyfZ3YB lNb7TuV4TIPJY2SvTdLPzxicnBHDo2cbP58oZUKUoWlRUgOCVw1p8mgEcFoWoAqv 061f9yac6RyoRyu03EQYiHlVLLcsQY4OcVcRjkfbzFi3HryYlhgLdp2iJJ7uQ5Iq J+hb/2WJl6UIgL14V7SJKQfkyDAxlmzl6zLrZbHZog== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledruddulecutefuodetggdotefrodftvfcurf hrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtredtre ertdenucfhrhhomhepfdfvohhmucflohhnvghsfdcuoehthhhjsehfrhgvvggsshgurdho rhhgqeenucggtffrrghtthgvrhhnpeekieefhfdtgeehjeejveeifeefhfeutdelhfejud evfeegfefgjeelueevhfejffenucffohhmrghinhepfhhrvggvsghsugdrohhrghenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhjsehfrh gvvggsshgurdhorhhg X-ME-Proxy: Feedback-ID: ib75146ab:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 829E6A60078; Thu, 28 Mar 2024 05:18:11 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-333-gbfea15422e-fm-20240327.001-gbfea1542 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 28 Mar 2024 09:17:51 +0000 From: "Tom Jones" To: freebsd-net@freebsd.org Subject: Re: vnet with interfaces Content-Type: text/plain X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.23 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.94)[-0.943]; R_DKIM_ALLOW(-0.20)[messagingengine.com:s=fm2]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.152:from]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : No valid SPF, DKIM not aligned (relaxed),none]; XM_UA_NO_VERSION(0.01)[]; FREEFALL_USER(0.00)[thj]; ARC_NA(0.00)[]; ASN(0.00)[asn:209242, ipnet:103.168.172.0/24, country:US]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all]; FROM_EQ_ENVFROM(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[messagingengine.com:+] X-Rspamd-Queue-Id: 4V4yd017Pvz4454 On Tue, Mar 26, 2024, at 18:31, Benoit Chesneau wrote: > How does work VNET with interfaces? Is this as efficient as using pci > passtrough in a vm ? Overhead should be minimal, while the device is logically missing from the default vnet there isn't any more "in the way" for actual usage. Marco's paper might be a good starting point for further digging: https://papers.freebsd.org/2003/zec-vimage/ Tom From nobody Thu Mar 28 10:24:31 2024 X-Original-To: freebsd-net@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 4V506J1CMRz5FW9V for ; Thu, 28 Mar 2024 10:25:12 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V506H09Qzz4H4l for ; Thu, 28 Mar 2024 10:25:11 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b="YoGazg/q"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2a00:1450:4864:20::535 as permitted sender) smtp.mailfrom=marietto2008@gmail.com Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-56c12c73ed8so938489a12.2 for ; Thu, 28 Mar 2024 03:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711621509; x=1712226309; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RaUMx98CG+ZnDBK6GknF9Kmsu7CFceWHgFbR1J0Ajqg=; b=YoGazg/qFUpuP182Yy12S714XiDOu7+6DiqWjzRffMaw0VX+Q810iKLEkchyuKB79l HChxglIFaFjrLVDaIScaqJCAylJOarxiFiHeR+OJxSYpSGYI2GC2d9g3DHXwENmvhGsp OdGv6YHu6pxJvjyav6AoxSLmlW1o1onnLxgZfEo614ULLL8dexjAwrrJiwd+ZcGj5zee uq+yqWZ024pHrJ0u0BKVi32UcMYks70w2ap5Gth0AMHQFRy+vVtpgyp2kHAFT8rCzIJZ 84mu3Q3zEu9fOgWxvihGXeV0nVHFjrkpXoX7KdVRdT0oBDjWIDg138nNoOeUnVrkz7uT WT7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711621509; x=1712226309; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=RaUMx98CG+ZnDBK6GknF9Kmsu7CFceWHgFbR1J0Ajqg=; b=LIdYUhPjSF3rmwUpfiLDxZ9haenatd/ruLaq1ZXcrRIEFzLK2VT+gxWlaNjqXRw/o5 HsR3IZdP2mOVJTHmAsEurvRakq0DIv4ThuiM+lx7QAuL7ij1JIiVC4F1EKQJd8JB5iol Uqa9B+R7armpN4qLagQPKu7lIICS3Ljvm4thjpetDFhYLUsEQzvNlWEFzVFR1h2q2QbY srV6+ljt0hjrIIY44R7JgTlL9Yjv87dKhdPY3cZW51JxTIikaqk1BkCTRNTwll6l232J ILjGBpz+7W71gFPoQJSh/PnYkWeLVu/sIlWQkRuWa4vrDOV9IpFzz4vn2NpSIatjKjrj SPOg== X-Forwarded-Encrypted: i=1; AJvYcCW4VvXLge1iO0RFF/P7FEA1zWiPmZznq/k3HxOZdlat2kwbozT0XahHS29Rt0aLQifEfdEMB5PrGsVHWY0mwKjFs5Cf9A4/mg== X-Gm-Message-State: AOJu0YwIVaIZ6L8EIUFUMINHsySqb6x+KvBi+us9L4oakaoCX552VkTs O6iP9PkYVm81L/d6PVLm/X9s3NxhozSKzKgbyEvRFJU0NspiSjhR+Oc8GxCmLGjsfPG5qS7XkT6 eplrCN0JWN0mqJWNBJHHEgMlSaGQ= X-Google-Smtp-Source: AGHT+IHdULjqFc6pgWVYdnxJoX9me0mwE4A1Qgc/0h9c1Q3RsTDrB8joA8mAJInt+WZhs7MB/Xw+SX7SxS5ENH3mqCQ= X-Received: by 2002:a17:906:2609:b0:a46:2ac1:c3f4 with SMTP id h9-20020a170906260900b00a462ac1c3f4mr1557133ejc.75.1711621508604; Thu, 28 Mar 2024 03:25:08 -0700 (PDT) List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Mario Marietto Date: Thu, 28 Mar 2024 11:24:31 +0100 Message-ID: Subject: Re: vnet with interfaces To: Tomek CEDRO Cc: Benoit Chesneau , "freebsd-net@FreeBSD.org" Content-Type: multipart/alternative; boundary="00000000000002aa9e0614b5f0a0" X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.93 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.93)[-0.928]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; MISSING_XM_UA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::535:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4V506H09Qzz4H4l --00000000000002aa9e0614b5f0a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ---> A very simple and elegant shell management tool to play with bhyve is vm-bhyve I never use it. I created my own elegant script that in my opinion works better than vm-bhyve. And I think that I can improve it.... I will... On Tue, Mar 26, 2024 at 8:30=E2=80=AFPM Tomek CEDRO wrot= e: > On Tue, Mar 26, 2024 at 7:32=E2=80=AFPM Benoit Chesneau > wrote: > > How does work VNET with interfaces? Is this as efficient as using pci > passtrough in a vm ? > > Beno=C3=AEt > > Vnet allows you to control networks by the system and make various > configurations networks jails etc, example here: > > > https://klarasystems.com/articles/virtualize-your-network-on-freebsd-with= -vnet/ > > PCI passthrough would skip all kernel networking and give your vm > access to the physical cable attached to a NIC. Note that passthrough > needs entry in /boot/loader.conf and disables that device for use in > system. I have a dedicated USB 3.0 controller working that way. > > A very simple and elegant shell management tool to play with bhyve is > vm-bhyve: > > https://www.freshports.org/sysutils/vm-bhyve/ > > Have fun :-) > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > --=20 Mario. --00000000000002aa9e0614b5f0a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
---> A very simple and elegant shell management to= ol to play with bhyve is vm-bhyve

I never use it. = I created my own elegant script that in my opinion works better than vm-bhy= ve. And I think that I can improve it....
I will...
=

= On Tue, Mar 26, 2024 at 8:30=E2=80=AFPM Tomek CEDRO <tomek@cedro.info> wrote:
On Tue, Mar 26, 2024 at = 7:32=E2=80=AFPM Benoit Chesneau
<benoitc= @enki-multimedia.eu> wrote:
> How does work VNET with interfaces? Is this as efficient as using pci = passtrough in a vm ?
> Beno=C3=AEt

Vnet allows you to control networks by the system and make various
configurations networks jails etc, example here:

https://klarasystems.= com/articles/virtualize-your-network-on-freebsd-with-vnet/

PCI passthrough would skip all kernel networking and give your vm
access to the physical cable attached to a NIC. Note that passthrough
needs entry in /boot/loader.conf and disables that device for use in
system. I have a dedicated USB 3.0 controller working that way.

A very simple and elegant shell management tool to play with bhyve is vm-bh= yve:

https://www.freshports.org/sysutils/vm-bhyve/

Have fun :-)

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info



--
Mario.
--00000000000002aa9e0614b5f0a0-- From nobody Thu Mar 28 14:00:58 2024 X-Original-To: net@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 4V54vW725Cz5FwtG; Thu, 28 Mar 2024 14:01:11 +0000 (UTC) (envelope-from eduardo@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 4V54vW5H7Wz4dv2; Thu, 28 Mar 2024 14:01:11 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1711634471; 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: in-reply-to:in-reply-to:references:references; bh=Z8Fgz2To4xjvfyXPzn6/M3cC9GrXPIqXvsovM+n+AHs=; b=pH0KDm0QO8lB/W1lC2ZtXOfKYBwPQVITO4j3OHJW4PFBSrW26FtCqTzWlIVJpb2W1Ic3ld mgADovlLu7jpBagEmZLunSAzc5kv+QV2upTdeeKENAhYbaCNcKQoH+X3qrFAEOXDwa10Ge IYIUyXg6hKT4ximBpr2sKDAPSzrDOXmNWciy1uVr4QjYI4SMdQrGN71rYsiCjZ4JzZbXz7 iK1kKuWyZvjjH/PjcG26+gNiDYQjN/X71iRcAlCQH5XaozV83JpdsrISvQPWnA+Ek5KG+Q eoHaKOUW4VwYacSVfNzpZA+fBfGaNprlJoj+/GYTCQNcrhOiE2W92Xl0Np05UA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1711634471; a=rsa-sha256; cv=none; b=Fzoy6IwH2uNNoDPDi4559ug/HDv7YlnLpmf1ae/q0P7jTTH8znz7Qv2KAQ3Sz8+21GH55n xxcGAyMa8Joy1USeb4OX8MkYNl1hIcCLKXe7EWBq8c4vZN7x+vhYpIPcNE4z3jEo9wvJzU QkTC54nHzch/YhT98rOjSNqfnR/Dr+a9uz96Xgvkbqr5XSU8o7e0rE3FC8fwFZh3/vuadD hyNcwSSOhMgRPXCcZHI5HH58fR+DpoNFh1bWmlMcCoJTICLVMmLWoUlXmxpsPE7ZTt/mJL J6R14GZ/9gU7Ny5/wtIaj6k3T4WS5gpGnyzGJURktXnEVXQrXxarLGKhiatEFA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1711634471; 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: in-reply-to:in-reply-to:references:references; bh=Z8Fgz2To4xjvfyXPzn6/M3cC9GrXPIqXvsovM+n+AHs=; b=F/8sL2RZPzzryWjH32+KXUGSqBhkhOuK71JLB+2rXooiZXm+pXuoZiXIxvUe2wvThAQrE1 stv0+4z4FRuHhMtvk15BWN/yF+iLP/BtDDEnFwnLylMPt73SM+69vQDI6Qfc1bwLdnl6ne EAkL+movyj/3G8dWuyUl7MYlvx8MVHWmco3lQ91/LaAdZHf36NaGf2RT6XxLyL3eBUykEu FLxXScq1nfgRYAwyf9kVOkDmslaO5Q4OHb1Dw+Y06aP/XgjIhtJAtktDKMw8/xYFUv2d1l 5ZyAYg9XQef87KMu9VgABwZtev9wFdrvUUqLEldRu8DcixG2muEl8sf4QGYzjw== Received: from mail-oi1-f178.google.com (mail-oi1-f178.google.com [209.85.167.178]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4V54vW4nBZz1CVc; Thu, 28 Mar 2024 14:01:11 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-oi1-f178.google.com with SMTP id 5614622812f47-3c3ca3c3bbaso603313b6e.0; Thu, 28 Mar 2024 07:01:11 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCVctPojx5j+jhNkb84XL3D0mGIAxAJ6MKg422EAxO0+KbfjKC6c8cL8+azwfkuZqOMldxbsf1qeMjuRRQk36+gmFoqrIZ1AmuNWHhj2jvnXefaR6gYKhqUO2XvdV76YcPlHHJH9o0np5d87rdaTSKAATvzL7laCthQV X-Gm-Message-State: AOJu0Yw+yS57fhvhKaDj0mh7qRVcjtPVpoBbXmK7qSMiftnHdoMVSF+R 3Wh93FWjv3NVMT2wmsewUoxqz/Pj9H+vFC9gynVZAxZcaZU9IL6crWM3d9AOFa8zQkaHJE6Ar6d N+th0BpZ5J8DfXUHB+lftLjmKorI= X-Google-Smtp-Source: AGHT+IEt4r3OmgtY+ivehZZtzjIaAoJwVNOTIfb5BfXb+zwUOuaYIBhBHJBZdmxzrayb2RrspRkC2+nNKXWqJFl4Y7s= X-Received: by 2002:a05:6808:dc7:b0:3c3:dddd:86b4 with SMTP id g7-20020a0568080dc700b003c3dddd86b4mr3083271oic.4.1711634470427; Thu, 28 Mar 2024 07:01:10 -0700 (PDT) List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 References: <6e795e9c-8de4-4e02-9a96-8fabfaa4e66f@app.fastmail.com> <6047C8EF-B1B0-4286-93FA-AA38F8A18656@karels.net> <8031cd99-ded8-4b06-93b3-11cc729a8b2c@app.fastmail.com> <38c54399-6c96-44d8-a3a2-3cc1bfbe50c2@app.fastmail.com> <27d8144f-0658-46f6-b8f3-35eb60061644@lakerest.net> In-Reply-To: From: Nuno Teixeira Date: Thu, 28 Mar 2024 14:00:58 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Request for Testing: TCP RACK To: Drew Gallatin Cc: Konstantin Belousov , rrs , Mike Karels , tuexen , garyj@gmx.de, current@freebsd.org, net@freebsd.org, Randall Stewart Content-Type: multipart/alternative; boundary="000000000000986d170614b8f4a6" --000000000000986d170614b8f4a6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello all! Running rack @b7b78c1c169 "Optimize HPTS..." very happy on my laptop (amd64)! Thanks all! Drew Gallatin escreveu (quinta, 21/03/2024 =C3=A0(s) 12:58): > The entire point is to *NOT* go through the overhead of scheduling > something asynchronously, but to take advantage of the fact that a > user/kernel transition is going to trash the cache anyway. > > In the common case of a system which has less than the threshold number > of connections , we access the tcp_hpts_softclock function pointer, make > one function call, and access hpts_that_need_softclock, and then return. > So that's 2 variables and a function call. > > I think it would be preferable to avoid that call, and to move the > declaration of tcp_hpts_softclock and hpts_that_need_softclock so that th= ey > are in the same cacheline. Then we'd be hitting just a single line in th= e > common case. (I've made comments on the review to that effect). > > Also, I wonder if the threshold could get higher by default, so that hpts > is never called in this context unless we're to the point where we're > scheduling thousands of runs of the hpts thread (and taking all those clo= ck > interrupts). > > Drew > > On Wed, Mar 20, 2024, at 8:17 PM, Konstantin Belousov wrote: > > On Tue, Mar 19, 2024 at 06:19:52AM -0400, rrs wrote: > > Ok I have created > > > > https://reviews.freebsd.org/D44420 > > > > > > To address the issue. I also attach a short version of the patch that > Nuno > > can try and validate > > > > it works. Drew you may want to try this and validate the optimization > does > > kick in since I can > > > > only now test that it does not on my local box :) > The patch still causes access to all cpu's cachelines on each userret. > It would be much better to inc/check the threshold and only schedule the > call when exceeded. Then the call can occur in some dedicated context, > like per-CPU thread, instead of userret. > > > > > > > R > > > > > > > > On 3/18/24 3:42 PM, Drew Gallatin wrote: > > > No. The goal is to run on every return to userspace for every thread= . > > > > > > Drew > > > > > > On Mon, Mar 18, 2024, at 3:41 PM, Konstantin Belousov wrote: > > > > On Mon, Mar 18, 2024 at 03:13:11PM -0400, Drew Gallatin wrote: > > > > > I got the idea from > > > > > > https://people.mpi-sws.org/~druschel/publications/soft-timers-tocs.pdf > > > > > The gist is that the TCP pacing stuff needs to run frequently, an= d > > > > > rather than run it out of a clock interrupt, its more efficient t= o > run > > > > > it out of a system call context at just the point where we return > to > > > > > userspace and the cache is trashed anyway. The current > implementation > > > > > is fine for our workload, but probably not idea for a generic > system. > > > > > Especially one where something is banging on system calls. > > > > > > > > > > Ast's could be the right tool for this, but I'm super unfamiliar > with > > > > > them, and I can't find any docs on them. > > > > > > > > > > Would ast_register(0, ASTR_UNCOND, 0, func) be roughly equivalent > to > > > > > what's happening here? > > > > This call would need some AST number added, and then it registers t= he > > > > ast to run on next return to userspace, for the current thread. > > > > > > > > Is it enough? > > > > > > > > > > Drew > > > > > > > > > > > > > > On Mon, Mar 18, 2024, at 2:33 PM, Konstantin Belousov wrote: > > > > > > On Mon, Mar 18, 2024 at 07:26:10AM -0500, Mike Karels wrote: > > > > > > > On 18 Mar 2024, at 7:04, tuexen@freebsd.org wrote: > > > > > > > > > > > > > > >> On 18. Mar 2024, at 12:42, Nuno Teixeira > > > > wrote: > > > > > > > >> > > > > > > > >> Hello all! > > > > > > > >> > > > > > > > >> It works just fine! > > > > > > > >> System performance is OK. > > > > > > > >> Using patch on main-n268841-b0aaf8beb126(-dirty). > > > > > > > >> > > > > > > > >> --- > > > > > > > >> net.inet.tcp.functions_available: > > > > > > > >> Stack D > > > > Alias PCB count > > > > > > > >> freebsd freebsd 0 > > > > > > > >> rack * > > > > rack 38 > > > > > > > >> --- > > > > > > > >> > > > > > > > >> It would be so nice that we can have a sysctl tunnable for > > > > this patch > > > > > > > >> so we could do more tests without recompiling kernel. > > > > > > > > Thanks for testing! > > > > > > > > > > > > > > > > @gallatin: can you come up with a patch that is acceptable > > > > for Netflix > > > > > > > > and allows to mitigate the performance regression. > > > > > > > > > > > > > > Ideally, tcphpts could enable this automatically when it > > > > starts to be > > > > > > > used (enough?), but a sysctl could select auto/on/off. > > > > > > There is already a well-known mechanism to request execution of > the > > > > > > specific function on return to userspace, namely AST. The > difference > > > > > > with the current hack is that the execution is requested for on= e > > > > callback > > > > > > in the context of the specific thread. > > > > > > > > > > > > Still, it might be worth a try to use it; what is the reason to > > > > hit a thread > > > > > > that does not do networking, with TCP processing? > > > > > > > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > Best regards > > > > > > > > Michael > > > > > > > >> > > > > > > > >> Thanks all! > > > > > > > >> Really happy here :) > > > > > > > >> > > > > > > > >> Cheers, > > > > > > > >> > > > > > > > >> Nuno Teixeira escreveu (domingo, > > > > 17/03/2024 =C3=A0(s) 20:26): > > > > > > > >>> > > > > > > > >>> Hello, > > > > > > > >>> > > > > > > > >>>> I don't have the full context, but it seems like the > > > > complaint is a performance regression in bonnie++ and perhaps other > > > > things when tcp_hpts is loaded, even when it is not used. Is that > > > > correct? > > > > > > > >>>> > > > > > > > >>>> If so, I suspect its because we drive the > > > > tcp_hpts_softclock() routine from userret(), in order to avoid tons > > > > of timer interrupts and context switches. To test this theory, yo= u > > > > could apply a patch like: > > > > > > > >>> > > > > > > > >>> It's affecting overall system performance, bonnie was jus= t > > > > a way to > > > > > > > >>> get some numbers to compare. > > > > > > > >>> > > > > > > > >>> Tomorrow I will test patch. > > > > > > > >>> > > > > > > > >>> Thanks! > > > > > > > >>> > > > > > > > >>> -- > > > > > > > >>> Nuno Teixeira > > > > > > > >>> FreeBSD Committer (ports) > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> -- > > > > > > > >> Nuno Teixeira > > > > > > > >> FreeBSD Committer (ports) > > > > > > > > > > > > > > > > > > > > > > > diff --git a/sys/netinet/tcp_hpts.c b/sys/netinet/tcp_hpts.c > > index 8c4d2d41a3eb..eadbee19f69c 100644 > > --- a/sys/netinet/tcp_hpts.c > > +++ b/sys/netinet/tcp_hpts.c > > @@ -216,6 +216,7 @@ struct tcp_hpts_entry { > > void *ie_cookie; > > uint16_t p_num; /* The hpts number one per cpu */ > > uint16_t p_cpu; /* The hpts CPU */ > > + uint8_t hit_callout_thresh; > > /* There is extra space in here */ > > /* Cache line 0x100 */ > > struct callout co __aligned(CACHE_LINE_SIZE); > > @@ -269,6 +270,11 @@ static struct hpts_domain_info { > > int cpu[MAXCPU]; > > } hpts_domains[MAXMEMDOM]; > > > > +counter_u64_t hpts_that_need_softclock; > > +SYSCTL_COUNTER_U64(_net_inet_tcp_hpts_stats, OID_AUTO, needsoftclock, > CTLFLAG_RD, > > + &hpts_that_need_softclock, > > + "Number of hpts threads that need softclock"); > > + > > counter_u64_t hpts_hopelessly_behind; > > > > SYSCTL_COUNTER_U64(_net_inet_tcp_hpts_stats, OID_AUTO, hopeless, > CTLFLAG_RD, > > @@ -334,7 +340,7 @@ SYSCTL_INT(_net_inet_tcp_hpts, OID_AUTO, precision, > CTLFLAG_RW, > > &tcp_hpts_precision, 120, > > "Value for PRE() precision of callout"); > > SYSCTL_INT(_net_inet_tcp_hpts, OID_AUTO, cnt_thresh, CTLFLAG_RW, > > - &conn_cnt_thresh, 0, > > + &conn_cnt_thresh, DEFAULT_CONNECTION_THESHOLD, > > "How many connections (below) make us use the callout based > mechanism"); > > SYSCTL_INT(_net_inet_tcp_hpts, OID_AUTO, logging, CTLFLAG_RW, > > &hpts_does_tp_logging, 0, > > @@ -1548,6 +1554,9 @@ __tcp_run_hpts(void) > > struct tcp_hpts_entry *hpts; > > int ticks_ran; > > > > + if (counter_u64_fetch(hpts_that_need_softclock) =3D=3D 0) > > + return; > > + > > hpts =3D tcp_choose_hpts_to_run(); > > > > if (hpts->p_hpts_active) { > > @@ -1683,6 +1692,13 @@ tcp_hpts_thread(void *ctx) > > ticks_ran =3D tcp_hptsi(hpts, 1); > > tv.tv_sec =3D 0; > > tv.tv_usec =3D hpts->p_hpts_sleep_time * HPTS_TICKS_PER_SLOT; > > + if ((hpts->p_on_queue_cnt > conn_cnt_thresh) && > (hpts->hit_callout_thresh =3D=3D 0)) { > > + hpts->hit_callout_thresh =3D 1; > > + counter_u64_add(hpts_that_need_softclock, 1); > > + } else if ((hpts->p_on_queue_cnt <=3D conn_cnt_thresh) && > (hpts->hit_callout_thresh =3D=3D 1)) { > > + hpts->hit_callout_thresh =3D 0; > > + counter_u64_add(hpts_that_need_softclock, -1); > > + } > > if (hpts->p_on_queue_cnt >=3D conn_cnt_thresh) { > > if(hpts->p_direct_wake =3D=3D 0) { > > /* > > @@ -1818,6 +1834,7 @@ tcp_hpts_mod_load(void) > > cpu_top =3D NULL; > > #endif > > tcp_pace.rp_num_hptss =3D ncpus; > > + hpts_that_need_softclock =3D counter_u64_alloc(M_WAITOK); > > hpts_hopelessly_behind =3D counter_u64_alloc(M_WAITOK); > > hpts_loops =3D counter_u64_alloc(M_WAITOK); > > back_tosleep =3D counter_u64_alloc(M_WAITOK); > > @@ -2042,6 +2059,7 @@ tcp_hpts_mod_unload(void) > > free(tcp_pace.grps, M_TCPHPTS); > > #endif > > > > + counter_u64_free(hpts_that_need_softclock); > > counter_u64_free(hpts_hopelessly_behind); > > counter_u64_free(hpts_loops); > > counter_u64_free(back_tosleep); > > > > --=20 Nuno Teixeira FreeBSD Committer (ports) --000000000000986d170614b8f4a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all!

Running rack @b7b= 78c1c169 "Optimize HPTS..." very happy on my laptop (amd64)!

Thanks all!

Drew Gallatin <gallatin@freebsd.org> escreveu (quinta, 21/= 03/2024 =C3=A0(s) 12:58):
The entir= e point is to *NOT* go through the overhead of scheduling something asynchr= onously, but to take advantage of the fact that a user/kernel transition is= going to trash the cache anyway.

In the commo= n case of a system which has less than the threshold=C2=A0 number of connec= tions , we access the tcp_hpts_softclock function pointer, make one functio= n call, and access hpts_that_need_softclock, and then return.=C2=A0 So that= 's 2 variables and a function call.

I thin= k it would be preferable to avoid that call, and to move the declaration of= tcp_hpts_softclock and hpts_that_need_softclock so that they are in the sa= me cacheline.=C2=A0 Then we'd be hitting just a single line in the comm= on case.=C2=A0 (I've made comments on the review to that effect).

Also, I wonder if the threshold could get higher by= default, so that hpts is never called in this context unless we're to = the point where we're scheduling thousands of runs of the hpts thread (= and taking all those clock interrupts).

Drew

On Wed, Mar 20, 2024, at 8:17 PM, Konstantin Be= lousov wrote:
On Tue, Mar 19, 2024 at 06:19:52AM -0400, rrs wrote:
> Ok I have created
>=C2=A0
>=C2=A0<= a href=3D"https://reviews.freebsd.org/D44420" target=3D"_blank">https://rev= iews.freebsd.org/D44420
>=C2=A0
>=C2= =A0
> To address the issue. I also attach a short version = of the patch that Nuno
> can try and validate
>=C2=A0
> it works. Drew you may want to try this and= validate the optimization does
> kick in since I can
<= /div>
>=C2=A0
> only now test that it does not on m= y local box :)
The patch still causes access to all cpu's= cachelines on each userret.
It would be much better to inc/c= heck the threshold and only schedule the
call when exceeded.= =C2=A0 Then the call can occur in some dedicated context,
lik= e per-CPU thread, instead of userret.

>=C2= =A0
>=C2=A0
> R
>=C2=A0<= br>
>=C2=A0
>=C2=A0
> On 3/1= 8/24 3:42 PM, Drew Gallatin wrote:
> > No.=C2=A0 The go= al is to run on every return to userspace for every thread.
&= gt; >=C2=A0
> > Drew
> >=C2=A0
> > On Mon, Mar 18, 2024, at 3:41 PM, Konstantin Belouso= v wrote:
> > > On Mon, Mar 18, 2024 at 03:13:11PM -0= 400, Drew Gallatin wrote:
> > > > I got the idea = from
> > > >=C2=A0https= ://people.mpi-sws.org/~druschel/publications/soft-timers-tocs.pdf
> > > > The gist is that the TCP pacing stuff needs to= run frequently, and
> > > > rather than run it o= ut of a clock interrupt, its more efficient to run
> > = > > it out of a system call context at just the point where we return= to
> > > > userspace and the cache is trashed an= yway. The current implementation
> > > > is fine = for our workload, but probably not idea for a generic system.
> > > > Especially one where something is banging on system ca= lls.
> > > >
> > > > As= t's could be the right tool for this, but I'm super unfamiliar with=
> > > > them, and I can't find any docs on t= hem.
> > > >
> > > > Wo= uld ast_register(0, ASTR_UNCOND, 0, func) be roughly equivalent to
> > > > what's happening here?
> >= ; > This call would need some AST number added, and then it registers th= e
> > > ast to run on next return to userspace, for = the current thread.
> > >=C2=A0
> &= gt; > Is it enough?
> > > >
>= > > > Drew
> > >=C2=A0
> = > > >
> > > > On Mon, Mar 18, 2024, at 2= :33 PM, Konstantin Belousov wrote:
> > > > > O= n Mon, Mar 18, 2024 at 07:26:10AM -0500, Mike Karels wrote:
&= gt; > > > > > On 18 Mar 2024, at 7:04,=C2=A0tuexen@freebsd.org wrote:
> > > > > >
> > > > &g= t; > >> On 18. Mar 2024, at 12:42, Nuno Teixeira
>= ; > > <ed= uardo@freebsd.org> wrote:
> > > > > >= ; >>
> > > > > > >> Hello all!<= br>
> > > > > > >>
> >= ; > > > > >> It works just fine!
> > = > > > > >> System performance is OK.
> &= gt; > > > > >> Using patch on main-n268841-b0aaf8beb126(-= dirty).
> > > > > > >>
= > > > > > > >> ---
> > > >= ; > > >> net.inet.tcp.functions_available:
> &= gt; > > > > >> Stack=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 D
> > >= ; Alias=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 PCB count
> > > > > >= >> freebsd freebsd=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 0
> > > > > > &= gt;> rack=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 *
> > > rack=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 38
> > > > > > >> ---
> > > > > > >>
> > > >= > > >> It would be so nice that we can have a sysctl tunnable = for
> > > this patch
> > > &g= t; > > >> so we could do more tests without recompiling kernel.=
> > > > > > > Thanks for testing!
> > > > > > >
> > > &g= t; > > > @gallatin: can you come up with a patch that is acceptabl= e
> > > for Netflix
> > > >= ; > > > and allows to mitigate the performance regression.
> > > > > >
> > > > >= > Ideally, tcphpts could enable this automatically when it
> > > starts to be
> > > > > > u= sed (enough?), but a sysctl could select auto/on/off.
> &g= t; > > > There is already a well-known mechanism to request execut= ion of the
> > > > > specific function on retu= rn to userspace, namely AST.=C2=A0 The difference
> > &= gt; > > with the current hack is that the execution is requested for = one
> > > callback
> > > >= > in the context of the specific thread.
> > > &= gt; >
> > > > > Still, it might be worth a = try to use it; what is the reason to
> > > hit a thr= ead
> > > > > that does not do networking, wit= h TCP processing?
> > > > >
>= > > > > >
> > > > > > Mike<= br>
> > > > > >
> > > &g= t; > > > Best regards
> > > > > > = > Michael
> > > > > > >>
=
> > > > > > >> Thanks all!
> = > > > > > >> Really happy here :)
> &= gt; > > > > >>
> > > > > >= ; >> Cheers,
> > > > > > >>
=
> > > > > > >> Nuno Teixeira <eduardo@freebsd.org&g= t; escreveu (domingo,
> > > 17/03/2024 =C3=A0(s) 20:= 26):
> > > > > > >>>
> > > > > > >>> Hello,
> > = > > > > >>>
> > > > > >= ; >>>> I don't have the full context, but it seems like the=
> > > complaint is a performance regression in bonn= ie++ and perhaps other
> > > things when tcp_hpts is= loaded, even when it is not used.=C2=A0 Is that
> > &g= t; correct?
> > > > > > >>>>
> > > > > > >>>> If so, I suspect= its because we drive the
> > > tcp_hpts_softclock()= routine from userret(), in order to avoid tons
> > >= ; of timer interrupts and context switches.=C2=A0 To test this theory,=C2= =A0 you
> > > could apply a patch like:
> > > > > > >>>
> > > &= gt; > > >>> It's affecting overall system performance, b= onnie was just
> > > a way to
> >= ; > > > > >>> get some numbers to compare.
> > > > > > >>>
> > > = > > > >>> Tomorrow I will test patch.
> = > > > > > >>>
> > > > >= ; > >>> Thanks!
> > > > > > >= ;>>
> > > > > > >>> --
> > > > > > >>> Nuno Teixeira
=
> > > > > > >>> FreeBSD Committer (ports)
> > > > > > >>
> >= > > > > >>
> > > > > > &= gt;>
> > > > > > >> --
> > > > > > >> Nuno Teixeira
> = > > > > > >> FreeBSD Committer (ports)
&= gt; > > > > >
> > > > >
> > >=C2=A0
> >=C2=A0
> diff --git a/sys/netinet/tcp_hpts.c b/sys/netinet/tcp_hpts= .c
> index 8c4d2d41a3eb..eadbee19f69c 100644
> --- a/sys/netinet/tcp_hpts.c
> +++ b/sys/netinet/tcp= _hpts.c
> @@ -216,6 +216,7 @@ struct tcp_hpts_entry {
<= /div>
>=C2=A0 void *ie_cookie;
>=C2=A0 uint16_t p= _num; /* The hpts number one per cpu */
>=C2=A0 uint16_t= p_cpu; /* The hpts CPU */
> + uint8_t hit_callout_thresh= ;
>=C2=A0 /* There is extra space in here */
>=C2=A0 /* Cache line 0x100 */
>=C2=A0 struct callo= ut co __aligned(CACHE_LINE_SIZE);
> @@ -269,6 +270,11 @@ s= tatic struct hpts_domain_info {
>=C2=A0 int cpu[MAXCPU];<= br>
>=C2=A0 } hpts_domains[MAXMEMDOM];
>=C2= =A0=C2=A0
> +counter_u64_t hpts_that_need_softclock;
> +SYSCTL_COUNTER_U64(_net_inet_tcp_hpts_stats, OID_AUTO, needs= oftclock, CTLFLAG_RD,
> +=C2=A0=C2=A0=C2=A0 &hpts_that= _need_softclock,
> +=C2=A0=C2=A0=C2=A0 "Number of hpt= s threads that need softclock");
> +
&g= t;=C2=A0 counter_u64_t hpts_hopelessly_behind;
>=C2=A0=C2= =A0
>=C2=A0 SYSCTL_COUNTER_U64(_net_inet_tcp_hpts_stats, O= ID_AUTO, hopeless, CTLFLAG_RD,
> @@ -334,7 +340,7 @@ SYSCT= L_INT(_net_inet_tcp_hpts, OID_AUTO, precision, CTLFLAG_RW,
&g= t;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &tcp_hpts_precision, 120,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "Value for PRE() precision of cal= lout");
>=C2=A0 SYSCTL_INT(_net_inet_tcp_hpts, OID_AU= TO, cnt_thresh, CTLFLAG_RW,
> -=C2=A0=C2=A0=C2=A0 &con= n_cnt_thresh, 0,
> +=C2=A0=C2=A0=C2=A0 &conn_cnt_thres= h, DEFAULT_CONNECTION_THESHOLD,
>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "How many connections (below) make us use the callout based mec= hanism");
>=C2=A0 SYSCTL_INT(_net_inet_tcp_hpts, OID_= AUTO, logging, CTLFLAG_RW,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= &hpts_does_tp_logging, 0,
> @@ -1548,6 +1554,9 @@ __t= cp_run_hpts(void)
>=C2=A0 struct tcp_hpts_entry *hpts;
>=C2=A0 int ticks_ran;
>=C2=A0=C2=A0
> + if (counter_u64_fetch(hpts_that_need_softclock) =3D=3D 0)
> + return;
> +
>=C2=A0 = hpts =3D tcp_choose_hpts_to_run();
>=C2=A0=C2=A0
>=C2=A0 if (hpts->p_hpts_active) {
> @@ -1683= ,6 +1692,13 @@ tcp_hpts_thread(void *ctx)
>=C2=A0 ticks_r= an =3D tcp_hptsi(hpts, 1);
>=C2=A0 tv.tv_sec =3D 0;
>=C2=A0 tv.tv_usec =3D hpts->p_hpts_sleep_time * HPTS_TICKS= _PER_SLOT;
> + if ((hpts->p_on_queue_cnt > conn_cnt_= thresh) && (hpts->hit_callout_thresh =3D=3D 0)) {
= > + hpts->hit_callout_thresh =3D 1;
> + counter_u6= 4_add(hpts_that_need_softclock, 1);
> + } else if ((hpts-&= gt;p_on_queue_cnt <=3D conn_cnt_thresh) && (hpts->hit_callout= _thresh =3D=3D 1)) {
> + hpts->hit_callout_thresh =3D = 0;
> + counter_u64_add(hpts_that_need_softclock, -1);
=
> + }
>=C2=A0 if (hpts->p_on_queue_cnt &= gt;=3D conn_cnt_thresh) {
>=C2=A0 if(hpts->p_direct_w= ake =3D=3D 0) {
>=C2=A0 /*
> @@ -1818,= 6 +1834,7 @@ tcp_hpts_mod_load(void)
>=C2=A0 cpu_top =3D = NULL;
>=C2=A0 #endif
>=C2=A0 tcp_pace.rp= _num_hptss =3D ncpus;
> + hpts_that_need_softclock =3D cou= nter_u64_alloc(M_WAITOK);
>=C2=A0 hpts_hopelessly_behind = =3D counter_u64_alloc(M_WAITOK);
>=C2=A0 hpts_loops =3D c= ounter_u64_alloc(M_WAITOK);
>=C2=A0 back_tosleep =3D coun= ter_u64_alloc(M_WAITOK);
> @@ -2042,6 +2059,7 @@ tcp_hpts_= mod_unload(void)
>=C2=A0 free(tcp_pace.grps, M_TCPHPTS);<= br>
>=C2=A0 #endif
>=C2=A0=C2=A0
> + counter_u64_free(hpts_that_need_softclock);
>=C2= =A0 counter_u64_free(hpts_hopelessly_behind);
>=C2=A0 co= unter_u64_free(hpts_loops);
>=C2=A0 counter_u64_free(back= _tosleep);





--
Nuno Teixeira
= FreeBSD Committer (ports)
--000000000000986d170614b8f4a6-- From nobody Thu Mar 28 15:53:35 2024 X-Original-To: net@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 4V57PS0PWyz5GBKB; Thu, 28 Mar 2024 15:53:48 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V57PR4qtzz4tK1; Thu, 28 Mar 2024 15:53:47 +0000 (UTC) (envelope-from tuexen@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (ip4d15f54e.dynamic.kabel-deutschland.de [77.21.245.78]) (Authenticated sender: micmac) by mail-n.franken.de (Postfix) with ESMTPSA id 36744721E2806; Thu, 28 Mar 2024 16:53:36 +0100 (CET) Content-Type: text/plain; charset=utf-8 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Subject: Re: Request for Testing: TCP RACK From: tuexen@freebsd.org In-Reply-To: Date: Thu, 28 Mar 2024 16:53:35 +0100 Cc: Drew Gallatin , Konstantin Belousov , rrs , Mike Karels , garyj@gmx.de, current@freebsd.org, net@freebsd.org, Randall Stewart Content-Transfer-Encoding: quoted-printable Message-Id: <5C9863F7-0F1C-4D02-9F6D-9DDC5FBEB368@freebsd.org> References: <6e795e9c-8de4-4e02-9a96-8fabfaa4e66f@app.fastmail.com> <6047C8EF-B1B0-4286-93FA-AA38F8A18656@karels.net> <8031cd99-ded8-4b06-93b3-11cc729a8b2c@app.fastmail.com> <38c54399-6c96-44d8-a3a2-3cc1bfbe50c2@app.fastmail.com> <27d8144f-0658-46f6-b8f3-35eb60061644@lakerest.net> To: Nuno Teixeira X-Mailer: Apple Mail (2.3774.500.171.1.1) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:680, ipnet:2001:638::/32, country:DE] X-Rspamd-Queue-Id: 4V57PR4qtzz4tK1 > On 28. Mar 2024, at 15:00, Nuno Teixeira wrote: >=20 > Hello all! >=20 > Running rack @b7b78c1c169 "Optimize HPTS..." very happy on my laptop = (amd64)! >=20 > Thanks all! Thanks for the feedback! Best regards Michael >=20 > Drew Gallatin escreveu (quinta, 21/03/2024 = =C3=A0(s) 12:58): > The entire point is to *NOT* go through the overhead of scheduling = something asynchronously, but to take advantage of the fact that a = user/kernel transition is going to trash the cache anyway. >=20 > In the common case of a system which has less than the threshold = number of connections , we access the tcp_hpts_softclock function = pointer, make one function call, and access hpts_that_need_softclock, = and then return. So that's 2 variables and a function call. >=20 > I think it would be preferable to avoid that call, and to move the = declaration of tcp_hpts_softclock and hpts_that_need_softclock so that = they are in the same cacheline. Then we'd be hitting just a single line = in the common case. (I've made comments on the review to that effect). >=20 > Also, I wonder if the threshold could get higher by default, so that = hpts is never called in this context unless we're to the point where = we're scheduling thousands of runs of the hpts thread (and taking all = those clock interrupts). >=20 > Drew >=20 > On Wed, Mar 20, 2024, at 8:17 PM, Konstantin Belousov wrote: >> On Tue, Mar 19, 2024 at 06:19:52AM -0400, rrs wrote: >>> Ok I have created >>>=20 >>> https://reviews.freebsd.org/D44420 >>>=20 >>>=20 >>> To address the issue. I also attach a short version of the patch = that Nuno >>> can try and validate >>>=20 >>> it works. Drew you may want to try this and validate the = optimization does >>> kick in since I can >>>=20 >>> only now test that it does not on my local box :) >> The patch still causes access to all cpu's cachelines on each = userret. >> It would be much better to inc/check the threshold and only schedule = the >> call when exceeded. Then the call can occur in some dedicated = context, >> like per-CPU thread, instead of userret. >>=20 >>>=20 >>>=20 >>> R >>>=20 >>>=20 >>>=20 >>> On 3/18/24 3:42 PM, Drew Gallatin wrote: >>>> No. The goal is to run on every return to userspace for every = thread. >>>>=20 >>>> Drew >>>>=20 >>>> On Mon, Mar 18, 2024, at 3:41 PM, Konstantin Belousov wrote: >>>>> On Mon, Mar 18, 2024 at 03:13:11PM -0400, Drew Gallatin wrote: >>>>>> I got the idea from >>>>>> = https://people.mpi-sws.org/~druschel/publications/soft-timers-tocs.pdf >>>>>> The gist is that the TCP pacing stuff needs to run frequently, = and >>>>>> rather than run it out of a clock interrupt, its more efficient = to run >>>>>> it out of a system call context at just the point where we return = to >>>>>> userspace and the cache is trashed anyway. The current = implementation >>>>>> is fine for our workload, but probably not idea for a generic = system. >>>>>> Especially one where something is banging on system calls. >>>>>>=20 >>>>>> Ast's could be the right tool for this, but I'm super unfamiliar = with >>>>>> them, and I can't find any docs on them. >>>>>>=20 >>>>>> Would ast_register(0, ASTR_UNCOND, 0, func) be roughly equivalent = to >>>>>> what's happening here? >>>>> This call would need some AST number added, and then it registers = the >>>>> ast to run on next return to userspace, for the current thread. >>>>>=20 >>>>> Is it enough? >>>>>>=20 >>>>>> Drew >>>>>=20 >>>>>>=20 >>>>>> On Mon, Mar 18, 2024, at 2:33 PM, Konstantin Belousov wrote: >>>>>>> On Mon, Mar 18, 2024 at 07:26:10AM -0500, Mike Karels wrote: >>>>>>>> On 18 Mar 2024, at 7:04, tuexen@freebsd.org wrote: >>>>>>>>=20 >>>>>>>>>> On 18. Mar 2024, at 12:42, Nuno Teixeira >>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>> Hello all! >>>>>>>>>>=20 >>>>>>>>>> It works just fine! >>>>>>>>>> System performance is OK. >>>>>>>>>> Using patch on main-n268841-b0aaf8beb126(-dirty). >>>>>>>>>>=20 >>>>>>>>>> --- >>>>>>>>>> net.inet.tcp.functions_available: >>>>>>>>>> Stack D >>>>> Alias PCB count >>>>>>>>>> freebsd freebsd 0 >>>>>>>>>> rack * >>>>> rack 38 >>>>>>>>>> --- >>>>>>>>>>=20 >>>>>>>>>> It would be so nice that we can have a sysctl tunnable for >>>>> this patch >>>>>>>>>> so we could do more tests without recompiling kernel. >>>>>>>>> Thanks for testing! >>>>>>>>>=20 >>>>>>>>> @gallatin: can you come up with a patch that is acceptable >>>>> for Netflix >>>>>>>>> and allows to mitigate the performance regression. >>>>>>>>=20 >>>>>>>> Ideally, tcphpts could enable this automatically when it >>>>> starts to be >>>>>>>> used (enough?), but a sysctl could select auto/on/off. >>>>>>> There is already a well-known mechanism to request execution of = the >>>>>>> specific function on return to userspace, namely AST. The = difference >>>>>>> with the current hack is that the execution is requested for one >>>>> callback >>>>>>> in the context of the specific thread. >>>>>>>=20 >>>>>>> Still, it might be worth a try to use it; what is the reason to >>>>> hit a thread >>>>>>> that does not do networking, with TCP processing? >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Mike >>>>>>>>=20 >>>>>>>>> Best regards >>>>>>>>> Michael >>>>>>>>>>=20 >>>>>>>>>> Thanks all! >>>>>>>>>> Really happy here :) >>>>>>>>>>=20 >>>>>>>>>> Cheers, >>>>>>>>>>=20 >>>>>>>>>> Nuno Teixeira escreveu (domingo, >>>>> 17/03/2024 =C3=A0(s) 20:26): >>>>>>>>>>>=20 >>>>>>>>>>> Hello, >>>>>>>>>>>=20 >>>>>>>>>>>> I don't have the full context, but it seems like the >>>>> complaint is a performance regression in bonnie++ and perhaps = other >>>>> things when tcp_hpts is loaded, even when it is not used. Is that >>>>> correct? >>>>>>>>>>>>=20 >>>>>>>>>>>> If so, I suspect its because we drive the >>>>> tcp_hpts_softclock() routine from userret(), in order to avoid = tons >>>>> of timer interrupts and context switches. To test this theory, = you >>>>> could apply a patch like: >>>>>>>>>>>=20 >>>>>>>>>>> It's affecting overall system performance, bonnie was just >>>>> a way to >>>>>>>>>>> get some numbers to compare. >>>>>>>>>>>=20 >>>>>>>>>>> Tomorrow I will test patch. >>>>>>>>>>>=20 >>>>>>>>>>> Thanks! >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>> Nuno Teixeira >>>>>>>>>>> FreeBSD Committer (ports) >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -- >>>>>>>>>> Nuno Teixeira >>>>>>>>>> FreeBSD Committer (ports) >>>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>=20 >>=20 >>> diff --git a/sys/netinet/tcp_hpts.c b/sys/netinet/tcp_hpts.c >>> index 8c4d2d41a3eb..eadbee19f69c 100644 >>> --- a/sys/netinet/tcp_hpts.c >>> +++ b/sys/netinet/tcp_hpts.c >>> @@ -216,6 +216,7 @@ struct tcp_hpts_entry { >>> void *ie_cookie; >>> uint16_t p_num; /* The hpts number one per cpu */ >>> uint16_t p_cpu; /* The hpts CPU */ >>> + uint8_t hit_callout_thresh; >>> /* There is extra space in here */ >>> /* Cache line 0x100 */ >>> struct callout co __aligned(CACHE_LINE_SIZE); >>> @@ -269,6 +270,11 @@ static struct hpts_domain_info { >>> int cpu[MAXCPU]; >>> } hpts_domains[MAXMEMDOM]; >>>=20 >>> +counter_u64_t hpts_that_need_softclock; >>> +SYSCTL_COUNTER_U64(_net_inet_tcp_hpts_stats, OID_AUTO, = needsoftclock, CTLFLAG_RD, >>> + &hpts_that_need_softclock, >>> + "Number of hpts threads that need softclock"); >>> + >>> counter_u64_t hpts_hopelessly_behind; >>>=20 >>> SYSCTL_COUNTER_U64(_net_inet_tcp_hpts_stats, OID_AUTO, hopeless, = CTLFLAG_RD, >>> @@ -334,7 +340,7 @@ SYSCTL_INT(_net_inet_tcp_hpts, OID_AUTO, = precision, CTLFLAG_RW, >>> &tcp_hpts_precision, 120, >>> "Value for PRE() precision of callout"); >>> SYSCTL_INT(_net_inet_tcp_hpts, OID_AUTO, cnt_thresh, CTLFLAG_RW, >>> - &conn_cnt_thresh, 0, >>> + &conn_cnt_thresh, DEFAULT_CONNECTION_THESHOLD, >>> "How many connections (below) make us use the callout based = mechanism"); >>> SYSCTL_INT(_net_inet_tcp_hpts, OID_AUTO, logging, CTLFLAG_RW, >>> &hpts_does_tp_logging, 0, >>> @@ -1548,6 +1554,9 @@ __tcp_run_hpts(void) >>> struct tcp_hpts_entry *hpts; >>> int ticks_ran; >>>=20 >>> + if (counter_u64_fetch(hpts_that_need_softclock) =3D=3D 0) >>> + return; >>> + >>> hpts =3D tcp_choose_hpts_to_run(); >>>=20 >>> if (hpts->p_hpts_active) { >>> @@ -1683,6 +1692,13 @@ tcp_hpts_thread(void *ctx) >>> ticks_ran =3D tcp_hptsi(hpts, 1); >>> tv.tv_sec =3D 0; >>> tv.tv_usec =3D hpts->p_hpts_sleep_time * HPTS_TICKS_PER_SLOT; >>> + if ((hpts->p_on_queue_cnt > conn_cnt_thresh) && = (hpts->hit_callout_thresh =3D=3D 0)) { >>> + hpts->hit_callout_thresh =3D 1; >>> + counter_u64_add(hpts_that_need_softclock, 1); >>> + } else if ((hpts->p_on_queue_cnt <=3D conn_cnt_thresh) && = (hpts->hit_callout_thresh =3D=3D 1)) { >>> + hpts->hit_callout_thresh =3D 0; >>> + counter_u64_add(hpts_that_need_softclock, -1); >>> + } >>> if (hpts->p_on_queue_cnt >=3D conn_cnt_thresh) { >>> if(hpts->p_direct_wake =3D=3D 0) { >>> /* >>> @@ -1818,6 +1834,7 @@ tcp_hpts_mod_load(void) >>> cpu_top =3D NULL; >>> #endif >>> tcp_pace.rp_num_hptss =3D ncpus; >>> + hpts_that_need_softclock =3D counter_u64_alloc(M_WAITOK); >>> hpts_hopelessly_behind =3D counter_u64_alloc(M_WAITOK); >>> hpts_loops =3D counter_u64_alloc(M_WAITOK); >>> back_tosleep =3D counter_u64_alloc(M_WAITOK); >>> @@ -2042,6 +2059,7 @@ tcp_hpts_mod_unload(void) >>> free(tcp_pace.grps, M_TCPHPTS); >>> #endif >>>=20 >>> + counter_u64_free(hpts_that_need_softclock); >>> counter_u64_free(hpts_hopelessly_behind); >>> counter_u64_free(hpts_loops); >>> counter_u64_free(back_tosleep); >>=20 >>=20 >=20 >=20 >=20 > --=20 > Nuno Teixeira > FreeBSD Committer (ports) From nobody Thu Mar 28 19:36:18 2024 X-Original-To: net@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 4V5DLC1v1nz5FrjV for ; Thu, 28 Mar 2024 19:36:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V5DLC0tgTz4SXv for ; Thu, 28 Mar 2024 19:36:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1711654579; a=rsa-sha256; cv=none; b=JKBVM3hqh7Fv3Dn53j3YvqpFSRRn6GPlYKw9hKTamoQLaMu5FDwLpTkXtlOgQUif4qYPRQ h8Mdyq8X38Zjbf0bIAWvLkwLCxIghi7KM+ng19Er21JpnJATv0r8vcw4rM07P4Sjf3lNvI 5GreAaz+M3RMhhiTAWCZA02erSn99jMlqHXhuTo46n2jUl5q2svAstd4PuNrcSfw+M8w92 PxlJ/YlpxAi9sok2OjyTBzDsfoayI2zfehnlmPugu5uGzd+EDPdo9rhPQRSDAcNb5O6jCO 0/plhawZK6Ee2fTnQ/NbaKM/JJbklljx2/5FhHcmnWXrk8vmZsrX9duFauViQg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1711654579; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kOJ72uOHFxvgQvXg7wUT3+yM/OtTiyUqojFkg4CVxAw=; b=lbBnTWsa54GVWsZRW4S7adPuhgL7SoUICI+gW0JZvVy6LljHFOt6JOD3HGlODCTsi+JHAl S4hA/rd2pa/lJP06F9QTU8OIJT+A1p4To43sH0uZ7IeuHOGQEH0A/cR7qyWcl7URigcYMG d569OrCSCqrSlUfOFaYoG6bv5Y1GaNksID0Prypf0UWYyVf5V0ghrf2s4CWPE+VIKRYA21 eg73y/0C+dlfA/iDTDNyMqlamUVEJxFmRubPNCUm4r2QVG24MwWtd2Yc5dSccgFDdgKVyR e0JtFv6g22mtcAEG2DCgTbOzDEgOpqtsFTGqpLtdN6/b55kHTHG9FTQrsnQEqg== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4V5DLC0VzSzgFN for ; Thu, 28 Mar 2024 19:36:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 42SJaIZJ040314 for ; Thu, 28 Mar 2024 19:36:18 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 42SJaI0g040313 for net@FreeBSD.org; Thu, 28 Mar 2024 19:36:18 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 277349] The net.inet.ip.source_address_validation should ignore CARP IP in backup state Date: Thu, 28 Mar 2024 19:36:18 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 14.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: glebius@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D277349 Gleb Smirnoff changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |FIXED --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Thu Mar 28 19:36:51 2024 X-Original-To: net@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 4V5DLr4QD3z5Frlr for ; Thu, 28 Mar 2024 19:36:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V5DLr3Pxgz4TD1 for ; Thu, 28 Mar 2024 19:36:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1711654612; a=rsa-sha256; cv=none; b=MuycQbQmZtbRnnJpPV538K2cwUmA4n5rO+piEOMji9XPFOC1dE/eKhehHcBoW4aBuEVKMB 2MWlZq7LN0d36O3Ha+BEGgh48Ga/lQRdBe+9pjHQDsNkZ6mpgYRs5C9kZehRLCF1Cpobfg f1svLdqa3TG0vhTooB43GgxDEKPq461OlOwIgXSgOAa2Fa8WOlx/aN8Tgh1CBmeeudNEEB o8crPy9jmhFfj4nm+Xobl6TQhtcTQJ/5k4Dcudf3MAHetA/mdZDnvdBg7a2OTWUh5iU7k9 eI55+R2xAcuqh5kMg6uHQWwK5m7VsxCss0W3i4emdJSMTC9eyHggDuqgC69Y2w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1711654612; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9NoBWieG2Ba4qQxMruRIQgMEDIROyief1mmY+4RdIU8=; b=CqqBTQ1YcWgFZc/MSY3K4OlFxtpOw/3pSBeUTvwhv9uLv9Ff+cyebQz+xCPkGpRKPCMeuB UBFl6EBBx1XtcTCKzGrrIu+6CstZXfcKhUkZsWxppeAXuud3JLRzUZoT6qca7h0fHI1Gvt dI8AA4pU79+LYdgjwC8xR0W0osZrHemi8QKh+BJGcfibejDr+kvWf2hCJj0Ie1Yxebys+v zg0y9ZlXHHNi8f6bM5ImZaulBH2iF2bo39DThvWN37Ia3uNPWeEbRYQ8pxp3qVjGqwzHGW PGVmIchPGyxTNSr1bjDWeKEjiSv7r7CiHgDAr2/FLcr8f9XPwS1hEQ5zpZWEuA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4V5DLr32Q2zgTs for ; Thu, 28 Mar 2024 19:36:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 42SJaq0t042508 for ; Thu, 28 Mar 2024 19:36:52 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 42SJaqti042506 for net@FreeBSD.org; Thu, 28 Mar 2024 19:36:52 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 277349] The net.inet.ip.source_address_validation should ignore CARP IP in backup state Date: Thu, 28 Mar 2024 19:36:51 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 14.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D277349 --- Comment #10 from commit-hook@FreeBSD.org --- A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3Dd6e1ae659b11a13a9c289424735394173= 907c1d3 commit d6e1ae659b11a13a9c289424735394173907c1d3 Author: Gleb Smirnoff AuthorDate: 2024-03-19 18:48:59 +0000 Commit: Gleb Smirnoff CommitDate: 2024-03-28 19:35:45 +0000 carp: check CARP status in in_localip_fib(), in6_localip_fib() Don't report a BACKUP CARP address as local. These two functions are u= sed only by source address validation for input packets, controlled by sysc= tls net.inet.ip.source_address_validation and net.inet6.ip6.source_address_validation. For this purpose we definitely want to treat BACKUP addresses as non local. This change is conservative and doesn't modify compat in_localip() and in6_localip(). They are used more widely than the FIB-aware versions. The change would modify the notion of ipfw(4) 'me' keyword. There might be other consequences as in_localip() is used by various tunneling protocols. PR: 277349 (cherry picked from commit 56f7860087eec14b4a65310b70bd704e79e1b48c) sys/netinet/in.c | 4 +++- sys/netinet6/in6.c | 4 +++- 2 files changed, 6 insertions(+), 2 deletions(-) --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sat Mar 30 02:11:32 2024 X-Original-To: net@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 4V613m6YDcz5Frk5 for ; Sat, 30 Mar 2024 02:11:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V613m5Hvyz4tPd for ; Sat, 30 Mar 2024 02:11:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1711764692; a=rsa-sha256; cv=none; b=Exz2WA0iP9heReah2Q6sDojMvnlPLxHXReBmECGtRJgVBtKzomydyOSaTkRwLk4iAYKpsC suBiPsiUqJr+ursmIW0o9m1X6uqe2SkgdbjB70eGRCVc4eetxqQaTY1th1SmzsSnw5UdOB /0a/nfUJ4+ohxkRhQuS6A1wkUAoZpZPaOPPc4e/zlg+M3tr9XF0ZuxOIpULhKNfE49iklf C8/QWPFDweYewqa4BlxtP3FXX22h053eExwQThgdlFYrIH6KuTVXPVKBnQEB8dM8rUIZm6 aBfTq/mdDfNbElyfLrlkz9O9DPcOWAW79r/hWJfIzFgwAC7dbUQ/uXc2tzqDXA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1711764692; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hgdSTRLpK8e+SvpRB0z9OcDMEPPpWpWljQ/bgxIfH/M=; b=ZY4M926K4g6/3W+EugTH+vWQ2HSr4WGLyyBQGa9xpha1SV9qfsgMgHLN6N4KlhN6crugMw lZBuR4y4e02eF/A+D0DLUnvIXMFPE2YFYqKiDRAlvCXRQOfTFwpXdGKPh9TgU6YMC6HXp1 MD1bxdmJfENmPEPm6nETFndPVbRfKapcn6ovvrQtOXNB7p4pGIVQjPDA92hA1G9EvyOZsX fvEato0w53mDNMuHZom+qFdhp3TViQOLByV+zPckxYFlyNXGyVnMThrvIF60Da7tQanUSO ZXYGzBMBhQU/REeQeCMLqz5Q5l9nMFKd4jUWl3mdtGJOFKvWJMsJO5mq7qBxQw== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4V613m4lCxzbyX for ; Sat, 30 Mar 2024 02:11:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 42U2BWAl047801 for ; Sat, 30 Mar 2024 02:11:32 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 42U2BWQT047800 for net@FreeBSD.org; Sat, 30 Mar 2024 02:11:32 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 278028] VXLAN interface is not working Date: Sat, 30 Mar 2024 02:11:32 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 14.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D278028 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |net@FreeBSD.org --- Comment #1 from Mark Linimon --- ^Triage: assign to net@, although it may just be a bug in the wiki documentation. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sat Mar 30 10:34:21 2024 X-Original-To: freebsd-net@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 4V6DDD2420z5FGXj for ; Sat, 30 Mar 2024 10:34:36 +0000 (UTC) (envelope-from benoitc@enki-multimedia.eu) Received: from mail-40136.proton.ch (mail-40136.proton.ch [185.70.40.136]) (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 "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V6DDB2FQHz4mKk for ; Sat, 30 Mar 2024 10:34:34 +0000 (UTC) (envelope-from benoitc@enki-multimedia.eu) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=enki-multimedia.eu header.s=protonmail2 header.b=KE3jBfxB; dmarc=pass (policy=none) header.from=enki-multimedia.eu; spf=pass (mx1.freebsd.org: domain of benoitc@enki-multimedia.eu designates 185.70.40.136 as permitted sender) smtp.mailfrom=benoitc@enki-multimedia.eu DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enki-multimedia.eu; s=protonmail2; t=1711794870; x=1712054070; bh=NYU40RXcTbMSWAVLuoYfg9XH7YD99nzYlKWp+hY1lI8=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=KE3jBfxBIZsV/25WAXTIfBDcEUm4SQQ+U19wvLJLkKCAl6XGL6FdxbX29heTmAooC X8GJwax68R8G6sj10p6oxedm774MBb3KqlbLq1GibS8AOPM60srJgMiMg5zfTr9Azv sNMB827HX/kmQtrdqfO4DD2HqHLsEK7MqgetBl05bYuVk3P+ijX7ipIRPLk9TULMW0 Au8BrCMIrowwftVHNzzesarN/ZDaS6s9AJANoJ1aiRljl8JwYi4x1cI526D5kItchk 7q9cKSFfQziV+HDXm3HLUGeRXxh8PdNEVKYSB8p+9/MQRFDTiBeEISdiS8jzmyEvMh KDbQzoKKNdVrA== Date: Sat, 30 Mar 2024 10:34:21 +0000 To: Tom Jones From: Benoit Chesneau Cc: freebsd-net@freebsd.org Subject: Re: vnet with interfaces Message-ID: In-Reply-To: References: Feedback-ID: 9066678:user:proton List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.16 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.958]; DMARC_POLICY_ALLOW(-0.50)[enki-multimedia.eu,none]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; R_DKIM_ALLOW(-0.20)[enki-multimedia.eu:s=protonmail2]; RWL_MAILSPIKE_VERYGOOD(-0.20)[185.70.40.136:from]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[enki-multimedia.eu:+] X-Rspamd-Queue-Id: 4V6DDB2FQHz4mKk Thanks for the link! the VIMAGE concept is such an interesting hack.. Beno=C3=AEt Chesneau, Enki Multimedia =E2=80=94 t. +33608655490=C2=A0 Sent with Proton Mail secure email. On Thursday, March 28th, 2024 at 10:17, Tom Jones wrote: >=20 > On Tue, Mar 26, 2024, at 18:31, Benoit Chesneau wrote: >=20 > > How does work VNET with interfaces? Is this as efficient as using pci > > passtrough in a vm ? >=20 >=20 > Overhead should be minimal, while the device is logically missing from th= e default vnet there isn't any more "in the way" for actual usage. Marco's = paper might be a good starting point for further digging: https://papers.fr= eebsd.org/2003/zec-vimage/ >=20 > Tom From nobody Sun Mar 31 15:23:30 2024 X-Original-To: net@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 4V6yb72VMdz5FlZj for ; Sun, 31 Mar 2024 15:23:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V6yb70hWKz4ksr for ; Sun, 31 Mar 2024 15:23:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1711898611; a=rsa-sha256; cv=none; b=fpEP5U3SyCj7qiVRYpOKuVpqjk2sVlKj43745uAyPU055ztN/Upy1MRoL/WLOsQ+wRVrau PEzlPuD0kWVxA1PWa19F5a/IRkxvqKCuZFa7ky4XarilKHZUOwtHP9p1VAgp8gYopWEMG8 QOeFbdpTkCyujiOFxEjMyuwFiVeW2yFlUZVxt9pHw+gVtWbtOQ17sIjm+5oPiNc9Zt4hxn md2NckvSAXfx3Gc5yZZuSE79VZU871VuUkjnUYlvLIyx5LYEaRwpFKUFwdVOulfyDqhY62 m0zh6aHQtS9OxEc9l34/D5PD0RiEvcGO/ac0DoaEPX/2JlNg6wzSaAADONTFgw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1711898611; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=n/NbGk6+d9GY+Fpq6Sa9K4tTUBhhMLEXPz9ub1vResA=; b=GaW8xV9JONNgrK7VHFDpZyHh5GQ0ZXunRZaI6XeSmd5Myc0ahQ1np8sZ2w0si4AMlJ39wa 5CGK7higO5Jjzq237WGlGSBg1/8u9vjYE/NmvNI2ThAP/5c4i85F1m+3FfVGH8goPTDMhf u8lEdAj1M7BICEjmDj5dQ/WUXGD5HBEvY6yV1CiBUfPd70LJX3oK3axNQxJdk0xsFiP4h/ q3QjGC70rbg54fHM+78zb/YNbYuXsqgvomNbCM0ibRM8Hwl6VuQl2SO6HcTwEIQLu82znU 6eTtkNzOg6IPnXNiuLqpGe8CSndTen3ifJat79vUPPQiKK0LhHvyKwWL9zRh9A== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4V6yb70J9zzjjM for ; Sun, 31 Mar 2024 15:23:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 42VFNUkP013598 for ; Sun, 31 Mar 2024 15:23:30 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 42VFNUg1013595 for net@FreeBSD.org; Sun, 31 Mar 2024 15:23:30 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 278028] VXLAN interface is not working Date: Sun, 31 Mar 2024 15:23:30 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 14.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: zlei@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D278028 Zhenlei Huang changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |zlei@FreeBSD.org --- Comment #2 from Zhenlei Huang --- (In reply to Ercan Deger from comment #0) Hi Ercan, Do you refer to the `Point to Point Example` or the `Multicast Example` ? --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Mar 31 21:00:54 2024 X-Original-To: net@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 4V764Q4FMDz5GQZ9 for ; Sun, 31 Mar 2024 21:00:54 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V764Q1qXtz4fjP for ; Sun, 31 Mar 2024 21:00:54 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1711918854; a=rsa-sha256; cv=none; b=yBAFwAOktikCUk5QJPnfmYozTEhQgdQh+HZ4WJX75JgRvUjObXuVx360TQE3p+rwngQEZe 3itwuHZQKFgKM9fxNUg0PXHZS66DHbi96RfQTNbR59m6fZfN8LdsUJL9yszQcVI7xY+DDF CZBC0PgD1vbflinuZoF2w3wxfiqIyWb2szRiuQLMy5CWDBKvyovPZdcEkTr2Y6b5tTowwA ARjtwyulgpjjwoqD9SRCV8rHouu2v/2lM3nXUgCkXE2WA4rD6AliP6dfmp8hg4ct6FcEUz TqyCrAjJNw96TJ4guKzgUA7E29dobLaxpIMsisrpR4XIt43VTMSsbWBdO7IjnA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1711918854; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=gzDaO7uoB/tChrza3AAFGR4pDDbi0RYRlRH+6RX9cuk=; b=VrAfT7SAhCpRoV4VM8z1HO6o+XOKGKmzhN4+688kngvcCrfbgOjMsV7/z/FndUo8SopBqN QYYoGvr+e8zxAkasnB+0UuqWX9k3aMEODAUgp7o0bbyyfGeV5XSlXLDA5sO0JN2bgUjxCT o5UgjL2s4tb8Ao1oNTUJ34ifQdp7pzixLILDaf3SBB/4zb7bPY6W2e52gFBcVkbvLMKe4d ixUH51wc1PuJzThCEkDODXk5XPC9OGp2K2GVlt7kJQhij5qAu9gCE4wceh5KUNplO2nMJV kae7vDYPU4pIWXNObR8gWIvZDM5QSJEwKh0oJFtLyC43ZGTW9AzuEjsos1KKXA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4V764Q1282ztF2 for ; Sun, 31 Mar 2024 21:00:54 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 42VL0s1X085666 for ; Sun, 31 Mar 2024 21:00:54 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 42VL0seR085665 for net@FreeBSD.org; Sun, 31 Mar 2024 21:00:54 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202403312100.42VL0seR085665@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: net@FreeBSD.org Subject: Problem reports for net@FreeBSD.org that need special attention Date: Sun, 31 Mar 2024 21:00:54 +0000 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="17119188540.bf22.73575" Content-Transfer-Encoding: 7bit --17119188540.bf22.73575 Date: Sun, 31 Mar 2024 21:00:54 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 254445 | cloned_interfaces="bridge0" does not respect net. Open | 200836 | iovctl(8): Return descriptions in the returned sc Open | 223824 | Panic in ng_base.c (netgraph) Open | 230807 | if_alc(4): Driver not working for Killer Networki Open | 232472 | ixgbe(4): SR-IOV passthru not working on Hyper-V Open | 234073 | ixl(4): Host X710-DA2 drops connect starting bhyv Open | 241106 | tun/ppp: panic: vm_fault: fault on nofault entry Open | 245981 | bnxt(4): BCM57414 / BCM57416 not initializing: bn Open | 256217 | [tcp] High system load because of interrupts with Open | 257038 | em(4): Panic on HTTP traffic to or from jail thro Open | 257286 | gateway with `ping -6 -e` is ignored Open | 258623 | cxgbe(4): Slow routing performance: 2 numa domain Open | 258850 | lagg(4): interface vanishes when both member inte Open | 261866 | ixgbe(4): Resets media type -> autoselect after s Open | 262024 | em(4): iflib handles bad packets incorrectly Open | 262093 | ixl(4): RX packet errors on Intel X710 after 12.2 Open | 263568 | ix(4): SR-IOV connection lost after loading VM wi In Progress | 118111 | rc: network.subr Add MAC address based interface 18 problems total for which you should take action. --17119188540.bf22.73575 Date: Sun, 31 Mar 2024 21:00:54 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" 
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.

Status      |    Bug Id | Description
------------+-----------+---------------------------------------------------
New         |    254445 | cloned_interfaces="bridge0" does not respect net.
Open        |    200836 | iovctl(8): Return descriptions in the returned sc
Open        |    223824 | Panic in ng_base.c (netgraph)
Open        |    230807 | if_alc(4): Driver not working for Killer Networki
Open        |    232472 | ixgbe(4): SR-IOV passthru not working on Hyper-V 
Open        |    234073 | ixl(4): Host X710-DA2 drops connect starting bhyv
Open        |    241106 | tun/ppp: panic: vm_fault: fault on nofault entry 
Open        |    245981 | bnxt(4): BCM57414 / BCM57416 not initializing: bn
Open        |    256217 | [tcp] High system load because of interrupts with
Open        |    257038 | em(4): Panic on HTTP traffic to or from jail thro
Open        |    257286 | gateway with `ping -6 -e` is ignored
Open        |    258623 | cxgbe(4): Slow routing performance: 2 numa domain
Open        |    258850 | lagg(4): interface vanishes when both member inte
Open        |    261866 | ixgbe(4): Resets media type -> autoselect after s
Open        |    262024 | em(4): iflib handles bad packets incorrectly
Open        |    262093 | ixl(4): RX packet errors on Intel X710 after 12.2
Open        |    263568 | ix(4): SR-IOV connection lost after loading VM wi
In Progress |    118111 | rc: network.subr Add MAC address based interface 

18 problems total for which you should take action.
--17119188540.bf22.73575--