From nobody Mon Jan 29 07:56:45 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 4TNgcS4slNz58QrV for ; Mon, 29 Jan 2024 07:56:56 +0000 (UTC) (envelope-from freebsd-net@c0decafe.de) Received: from mail.c0decafe.de (mail.c0decafe.de [IPv6:2a01:4f8:222:100a::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.c0decafe.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TNgcR1RyDz4bPB for ; Mon, 29 Jan 2024 07:56:55 +0000 (UTC) (envelope-from freebsd-net@c0decafe.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=c0decafe.de header.s=c0decafe.de header.b=g1ha8zXu; dmarc=pass (policy=none) header.from=c0decafe.de; spf=pass (mx1.freebsd.org: domain of freebsd-net@c0decafe.de designates 2a01:4f8:222:100a::2 as permitted sender) smtp.mailfrom=freebsd-net@c0decafe.de Received: from [172.17.30.254] (unknown [172.17.30.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.c0decafe.de (Postfix) with ESMTPSA id BF22A10541E; Mon, 29 Jan 2024 08:56:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=c0decafe.de; s=c0decafe.de; t=1706515005; bh=mGhvhY7EOdy1G4ABoXtiUfiVm/mkCNCdXeH0KqIuJ9k=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=g1ha8zXurdHzJDJ4nOfByD+ev76G68+Bv+9Pxm4jfKjgrE/eRucfc+y+15P8JdDik 7JEtniIUpERJ+IohTrmVxtzfoCyOkkNgm8s9C9993bIcNw0elIynRZSASOCIZFMn/f nC9unZu8XaiiGDHYJYxhSEVyZ3+vFqR4RumtGx9I= Content-Type: multipart/alternative; boundary="------------h3cIX2ZczcxnZIWUnT9s5GDd" Message-ID: Date: Mon, 29 Jan 2024 08:56:45 +0100 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 User-Agent: Mozilla Thunderbird Subject: Re: problem with ixl(4) and vlans Content-Language: en-US To: Santiago Martinez Cc: freebsd-net@freebsd.org References: <401ae00d-730c-4ac7-a18c-a2b1b75b3edf@c0decafe.de> <063A269F-B479-4A43-8E3B-B044C2E779F0@codenetworks.net> From: Daniel Autocrypt: addr=mail@c0decafe.de; keydata= xsFNBFuKxS8BEADGswc2TX/b65QzcDw+b/W30LGgJXEn/GUnV8SqTNI5G3LoJLzJkVZtXh21 ng3wkc13JBD7Vb1yC6NRrmFUf77Gq3uyDVnqaKreMmZRgds9/uLFHiYM8NNEm/IjdY3nbhlk +WW/Reae8PVk7lOrO0VNcy+rwm/hJF8hFGzzBCx4tEyVZw5O4FPGAiD/SkM+FD5veupcuzI8 qkuuaInuuP8oZ4fTqdJTd1JvkRLMvytqHBx744v2Pg9Oos0ucxXYpTMXVIYO1S3KxJFyiRuO sxc+jtEft/2VwMNVp2wFssboHIMc9rKziJVHadfqBY4LxqVPhgbExjK3f65RmvZ/d/dEsF3I mTgyr4sIi1OBFLapxLdzzH1QYc6HVDVMDnndckS/4spHCKnCsPsKkeEx+L2lwAlr6PwE9xMi BtM+2NjMXN4g6u9SmIxoIHcIDOQwpmtFp70UB3SBZlIParjmZysIN9fSOtzBksuSUFGJ7PP+ lo/96PW1u6OBDocRBdtTD5710d9tsGluU4S86BVdytn/u/QAoEviae29arUYIGsMR9oeJhJc wEqRS4KfEuMhzjhJQDyJ4fLE7MKB5rGPdvhIhY7XqjKVTBIoRABZzYaPeHDvLyP83G0qye3l mwE6E8xsDPBZ4cFgZPl6xkLWugHiRVkE8VsY/RM3+v323ZvT9QARAQABzRlEYW5pZWwgPG1h aWxAYzBkZWNhZmUuZGU+wsGUBBMBCgA+FiEEw5F1cA3yVgaiOsGl9pDM4NUKhiIFAluKxS8C GyMFCRLMAwAFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AACgkQ9pDM4NUKhiKRLw//XhDaN9QY o5lotBPWJSosFCdiEJBgMKfIWFmg8HgKbRVbxPV025zFXYU2WEMcymMw0cZEMCS3KtsvsyTv M04Qi5U5fxGs8RWTi8VuclUZQ96wJjWu9yDIL0jfOyzibq2Gi4zE2DE5zGd27Zpe/mHNlpmO 6wojZur5H5VaP+Mfeb5vq7D8oJJwLI7/qtZgesJzIv2rDy5og8CyCjM9uZKAAWTxCV6j6qUX K9DNanx16NBT3bTGA1AxqkvuogRmbY+GWqb+Jjtz0uOdUY4BQhW3rM30kOZybtmResaHwtaT EQm6YVKns2rAFzVS4Vcn9rYB4RJ5ovUCjk90tBXZrR2XvWJenckC+9oOkc4uoYF28lOzFoBa C/P4DzlVag5AiJTF7R2mHCnOj3wBKQqV1VhyHnqHGpVbwPEAbm0RX97lAn5cSLJ9ZFCY+Hin 1Ssh1hjA0McQNs9uFSyNj8HSfwenn5wqA6zwJzCaYONPNWZs3ejajCOOHyMoSswbkC/uupPA GvFaZdb34n6C3ShuUfr6DqbTbp+xER2sl/QQnrZ5cpPwEo4bG4aaEi0T0LbLcCZgVLQzC3iw BfjOHKjx9AIEOENbVjw5aTAEA6IPPJVvqMIjTy9lbTO/dteOpHfQ4lbeMyenYMVmHeiTeNA3 yV9KKWkrdr0C1VvpDM9/Z9uHMWHOwU0EW4rFLwEQALPCXxjWvvbQca6wmu8GzBZ0ymUd2eDq B7CTJmfR7FwvAIzNslGKH+kUIF18EnfDYiTBlsJCrCLaRsrGtUfNOmti0qVi/fjfllasicpp S+oxC2yBcGvGhm3/HH9g9HkezvEM4QOjsPjKLZMi+suVYRipaSJCf3RGRdCh9vxmN0MLRMoe 1jHVr94BvgQo4ktaFn8ACl2Z5351uOmedL1y3/LgmUyCm/vCa9z5YRb9sp3h5YQyEupFae2x i8NoDrm0StHcKAGucz04DwV2hC2NWL9UfJKhqC1l8gx7NkcohE8nEbMmRcuc9vhGUPquIMm3 ejvd5XGetN7lKC+5YVeG0e7kiCPIwNnON22dEMWv1bCuYXUoLDkejlKCqX+n8xC8Ddao+5t1 7oLXYQJqTaFKz67kxKJG/gXRBDXWrkdQ/7tE7qZbHTqaREEXRA1SYLxJGCNSUzt4kkq0kuvB AI6f72EYj5GZPKENIRZAbHv6pDy9qd9f6cB+qj1Cz7zqfDPLpN228nV88T0Fq5QH4s9KLXSs vT4nyKz5p0I+u4IydOKLwEqcjlqMNwIaBEZTjD8UFNnd8mCJcwn7uZiKWobjU2jJRU2SmROP /WjDHEff2SmJws7FVVmoyPl/FRD4QYDtuu9qwqh1tU1ut73PXxMoB/IHNkjBe5g++R1tvXWE fF0ZABEBAAHCwXwEGAEKACYWIQTDkXVwDfJWBqI6waX2kMzg1QqGIgUCW4rFLwIbDAUJEswD AAAKCRD2kMzg1QqGIoofD/9tB2wD6G7nAL9mWEC79Kusioh2HNn7HqUnB0HcGb6jD9coD8BK 1Io/1Z//slcw9+2FFwP4AXv0DTmYhb/zNX/SPrTQqSP2TPgaecVyIHzK5r5hqNE6nponvUVe jJfIzTJ5r+eKxuuMi/BkltZC98IuQV0PRLHlrVRKHWgRH/YGyFZ/OXRGeoxwZhkFE3ftwr+o ORz3ZZJIGjJpQGK3ujZ328qiswfNN3g65GoW2HU9LlWul6UgM8lFdIfOmvZqzGPnHEvPzidi q+/dezdTWFJtifQHjdpWYNnO2141N+1fU+tH7dt4TxdN1KP600BXvD29jWxPnnA6fSOyAxYT wdZOrDwrftWMF97dOIVrvhnC3Sm7PwtK639ksP2eCHWn532S4A3Ikb7xoPnuFeAXM9o9/9In yqKixsI+JodUY+wpTJsqkvhzPtrnzH+rwPSB9mpnbajRqVZ0qR0n2z8IkYhvqhIOwD5BBj// RjfZNvxaQ94UFxyqbEWOnBv5osYbprO1eZwJnNvYuf0bCaYKJX/UM87GbgTimDp1jolmJ0Nw KZRkdfs+a1j480Xt/Pyzr/muuGmFRk7/gj1tRkxAeKSdsUW88il88ZXPEwDT0BRzXo51tiiu dSHhtMS24Qzevf3cP93tAanM4Xni6Tu10ZveOALJYC5T161VfZAur0yJBA== In-Reply-To: <063A269F-B479-4A43-8E3B-B044C2E779F0@codenetworks.net> X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[c0decafe.de,none]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[c0decafe.de:s=c0decafe.de]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; XM_UA_NO_VERSION(0.01)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_ONE(0.00)[1]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[c0decafe.de:+] X-Rspamd-Queue-Id: 4TNgcR1RyDz4bPB This is a multi-part message in MIME format. --------------h3cIX2ZczcxnZIWUnT9s5GDd Content-Type: text/plain; charset=UTF-8; format=flowed X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit Hi Santi, yes that was one of the first things i tried, disabling all the VLAN_HW* options on the interface, unfortunately without any change in the behavior. The pf module is loaded and some filters are active on another interface but no filtering happens on ixl3, ixl3.15 or bridge0. That was also one of the reasons why I crosschecked my setup with an USB nic so I can make sure its not the firewall by accident. Thanks & Best Daniel On 1/25/24 22:10, Santiago Martinez wrote: > Hi Daniel, > > have you try disabling hardware vlan filtering? > > Also I guess there is not ipfw or pf modules loaded right? > > Best > Santi > >> On 25 Jan 2024, at 10:07, Daniel wrote: >> >>  >> >> Hi, >> >> thanks for your suggestion. Turns out, when i unplug the vlan >> interface from the bridge and put the ip address on the vlan >> interface, as you suggested, things start to work, e.g. arp resolves. >> >> as soon as i put the ip and the vlan interface back on the bridge, >> things stop again. so where does this lead me? the problem is not in >> the vlan handling, but on the bridge? >> >> I started playing with the net.link.bridge sysctls and indeed, when i >> set >> >> >> # sysctl net.link.bridge.inherit_mac=1 >> >> >> and then recreate the bridge >> >> >> # ifconfig bridge0 deletem ixl3.15 deletem vnet0.1 >> # ifconfig bridge0 addm ixl3.15 addm vnet0.1 >> >> >> with the ip address still on bridge0 and ixl3, ixl3.15 and bridge0 >> all sharing the same mac address, arp starts resolving. but only for >> requests sent from the bridge0 interface. inside of the jail things >> still don't work (as the vnet interface again has another mac address). >> >> >> # ifconfig ixl3 >> ixl3: flags=28963 >> metric 0 mtu 1500 >> options=4a500b9 >>         ether a4:bf:01:76:ef:9d >>         media: Ethernet autoselect (10Gbase-SR ) >>         status: active >>         nd6 options=29 >> # ifconfig ixl3.15 >> ixl3.15: flags=8943 >> metric 0 mtu 1500 >>         options=4200001 >>         ether a4:bf:01:76:ef:9d >>         groups: vlan >>         vlan: 15 vlanproto: 802.1q vlanpcp: 0 parent interface: ixl3 >>         media: Ethernet autoselect (10Gbase-SR ) >>         status: active >>         nd6 options=29 >> # ifconfig bridge0 >> bridge0: flags=8843 metric 0 >> mtu 1500 >>         ether a4:bf:01:76:ef:9d >>         inet 192.168.55.20 netmask 0xffffff00 broadcast 192.168.55.255 >>         id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 >>         maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 >>         root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 >>         member: vnet0.1 flags=143 >>                 ifmaxaddr 0 port 9 priority 128 path cost 2000 >>         member: ixl3.15 flags=143 >>                 ifmaxaddr 0 port 8 priority 128 path cost 2000 >>         groups: bridge >>         nd6 options=9 >> # ping 192.168.55.1 >> PING 192.168.55.1 (192.168.55.1): 56 data bytes >> ^C >> --- 192.168.55.1 ping statistics --- >> 2 packets transmitted, 0 packets received, 100.0% packet loss >> >> [! yes, the host does not answer on ICMP, but that is to be expected !] >> >> # arp -an >> ? (192.168.55.20) at a4:bf:01:76:ef:9d on bridge0 permanent [bridge] >> ? (192.168.55.1) at b8:27:eb:47:8f:43 on bridge0 expires in 1197 >> seconds [bridge] >> [...] >> >> [! into the jail !] >> >> JAIL # ifconfig epair0b >> epair0b: flags=8863 metric 0 >> mtu 1500 >>         options=8 >>         ether ac:16:2d:bd:b7:34 >>         hwaddr 02:51:73:d1:33:0b >>         inet 192.168.55.10 netmask 0xffffff00 broadcast 192.168.55.255 >>         inet6 fe80::ae16:2dff:febd:b734%epair0b prefixlen 64 scopeid 0x2 >>         groups: epair >>         media: Ethernet 10Gbase-T (10Gbase-T ) >>         status: active >>         nd6 options=21 >> JAIL # ping 192.168.55.1 >> PING 192.168.55.1 (192.168.55.1): 56 data bytes >> ^C >> --- 192.168.55.1 ping statistics --- >> 1 packets transmitted, 0 packets received, 100.0% packet loss >> JAIL # arp -an >> ? (192.168.55.10) at ac:16:2d:bd:b7:34 on epair0b permanent [ethernet] >> ? (192.168.55.1) at (incomplete) on epair0b expired [ethernet] >> >> >> I conclude that there must be some mac address filtering going on in >> the data path, whether its on ixl or the bridge. >> >> In dmesg I also see: >> >> >> bridge0: can't disable some capabilities on ixl3.15: 0x400 >> >> but as of /usr/src/sys/net/if.h:233 this maps to IFCAP_LRO which >> afaik should not have any influence on L2 filtering. >> >> >> Have to say, I'm out of ideas again. Never had something like this. >> So far just 'throwing interfaces on a bridge' worked in the past. Any >> ideas where to look next? >> >> >> Thanks a lot & best >> >> >> Daniel >> >> >> On 1/25/24 08:22, Zhenlei Huang wrote: >>> >>> >>>> On Jan 23, 2024, at 11:03 PM, Daniel wrote: >>>> >>>> Hi List, >>>> >>>> >>>> just recently I discovered a problem with the ixl(4) driver. >>>> Hopefully someone here can help me. my setup is as follows: >>>> >>>> >>>> Network ----- ixl3 interface ----- ixl3.15 vlan interface ----- >>>> bridge0 ----- vnet0.1 to jail >>>> >>>> >>>> the problem now is that the jail can send data out (arp requests), >>>> i do see the responses on the ixl3 interface of the host, but they >>>> never make their way up to the ixl3.15 vlan interface (even though >>>> they are tagged correctly). To rule out that my config or the >>>> network is the cruel pit i did test the same setup with a cheap >>>> usb-ethernet adapter and there everything works as expected. I'm on >>>> FreeBSD 13.2-RELEASE-p8 and I did test both, the in kernel driver >>>> and the driver from ports intel-ixl-kmod-1.13.4_1. >>>> >>> I would encourage you to do plain VLAN tests, i.e. plug ixl3.15 out >>> from bridge0 >>> >>> ``` >>> # ifconfig bridge0 deletem ixl3.15 >>> # ifconfig bridge0 inet 192.168.55.20/24 delete ### to prevent confusion >>> # ifconfig ixl3.15 inet 192.168.55.x/24 >>> # ping -c1 192.168.55.1 >>> ``` >>> >>>> >>>> Here is a bit of information on my environment: >>>> >>>> # uname -a >>>> FreeBSD mimir 13.2-RELEASE-p8 FreeBSD 13.2-RELEASE-p8 GENERIC amd64 >>>> >>>> # pciconf -lBbcevV pci0:25:0:3 >>>> ixl3@pci0:25:0:3:       class=0x020000 rev=0x09 hdr=0x00 >>>> vendor=0x8086 device=0x37d3 subvendor=0x8086 subdevice=0x35d5 >>>>     vendor     = 'Intel Corporation' >>>>     device     = 'Ethernet Connection X722 for 10GbE SFP+' >>>>     class      = network >>>>     subclass   = ethernet >>>>     bar   [10] = type Prefetchable Memory, range 64, base >>>> 0xb0000000, size 16777216, enabled >>>>     bar   [1c] = type Prefetchable Memory, range 64, base >>>> 0xb5000000, size 32768, enabled >>>>     cap 01[40] = powerspec 3  supports D0 D3 current D0 >>>>     cap 05[50] = MSI supports 1 message, 64 bit, vector masks >>>>     cap 11[70] = MSI-X supports 129 messages, enabled >>>>                  Table in map 0x1c[0x0], PBA in map 0x1c[0x1000] >>>>     cap 10[a0] = PCI-Express 2 endpoint max data 256(512) FLR RO >>>>                  max read 512 >>>>                  link x1(x1) speed 2.5(2.5) ASPM disabled(L0s/L1) >>>>     cap 03[e0] = VPD >>>>     ecap 0001[100] = AER 2 0 fatal 0 non-fatal 1 corrected >>>>     ecap 0003[140] = Serial 1 9aef76ffff01bfa4 >>>>     ecap 000e[150] = ARI 1 >>>>     ecap 0010[160] = SR-IOV 1 IOV disabled, Memory Space disabled, >>>> ARI disabled >>>>                      0 VFs configured out of 32 supported >>>>                      First VF RID Offset 0x006d, VF RID Stride 0x0001 >>>>                      VF Device ID 0x37cd >>>>                      Page Sizes: 4096 (enabled), 8192, 65536, >>>> 262144, 1048576, 4194304 >>>>     ecap 0017[1a0] = TPH Requester 1 >>>>     ecap 000d[1b0] = ACS 1 Source Validation unavailable, >>>> Translation Blocking unavailable >>>>                      P2P Req Redirect unavailable, P2P Cmpl >>>> Redirect unavailable >>>>                      P2P Upstream Forwarding unavailable, P2P >>>> Egress Control unavailable >>>>                      P2P Direct Translated unavailable, Enhanced >>>> Capability unavailable >>>>   PCI-e errors = Correctable Error Detected >>>>                  Unsupported Request Detected >>>>      Corrected = Advisory Non-Fatal Error >>>>     VPD ident  = 'Example VPD' >>>> >>>> # ifconfig >>>> [...] >>>> ixl3: flags=8963 >>>> metric 0 mtu 1500 >>>> options=4a500b9 >>>>         ether a4:bf:01:76:ef:9d >>>>         media: Ethernet autoselect (10Gbase-SR ) >>>>         status: active >>>>         nd6 options=29 >>>> ixl3.15: flags=8942 >>>> metric 0 mtu 1500 >>>> options=4200001 >>>>         ether a4:bf:01:76:ef:9d >>>>         groups: vlan >>>>         vlan: 15 vlanproto: 802.1q vlanpcp: 0 parent interface: ixl3 >>>>         media: Ethernet autoselect (10Gbase-SR ) >>>>         status: active >>>>         nd6 options=29 >>>> bridge0: flags=8843 metric >>>> 0 mtu 1500 >>>>         ether 58:9c:fc:10:dd:05 >>>>         inet 192.168.55.20 netmask 0xffffff00 broadcast 192.168.55.255 >>>>         id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 >>>>         maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 >>>>         root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 >>>>         member: vnet0.1 flags=143 >>>>                 ifmaxaddr 0 port 9 priority 128 path cost 2000 >>>>         member: ixl3.15 flags=143 >>>>                 ifmaxaddr 0 port 8 priority 128 path cost 55 >>>>         groups: bridge >>>>         nd6 options=9 >>>> [...] >>>> >>>> >>>> >>>> # cat /etc/rc.conf >>>> [...] >>>> ifconfig_ixl3="up" >>>> vlans_ixl3="15" >>>> cloned_interfaces="bridge0" >>>> ifconfig_bridge0="addm ixl3.15 up" >>>> [...] >>>> >>>> >>>> >>>> # dmesg | grep ixl >>>> ixl0: >>>> mem 0xb3000000-0xb3ffffff,0xb5018000-0xb501ffff at device 0.0 >>>> numa-domain 0 on pci6 >>>> ixl0: fw 3.1.55727 api 1.5 nvm 3.31 etid 80000d32 oem 1.262.0 >>>> ixl0: PF-ID[0]: VFs 32, MSI-X 129, VF MSI-X 5, QPs 384, MDIO shared >>>> ixl0: Using 1024 TX descriptors and 1024 RX descriptors >>>> ixl0: Using 12 RX queues 12 TX queues >>>> ixl0: Using MSI-X interrupts with 13 vectors >>>> ixl0: Ethernet address: a4:bf:01:76:ef:9a >>>> ixl0: Allocating 16 queues for PF LAN VSI; 12 queues active >>>> ixl0: SR-IOV ready >>>> ixl0: netmap queues/slots: TX 12/1024, RX 12/1024 >>>> ixl1: >>>> mem 0xb2000000-0xb2ffffff,0xb5010000-0xb5017fff at device 0.1 >>>> numa-domain 0 on pci6 >>>> ixl1: fw 3.1.55727 api 1.5 nvm 3.31 etid 80000d32 oem 1.262.0 >>>> ixl1: PF-ID[1]: VFs 32, MSI-X 129, VF MSI-X 5, QPs 384, MDIO shared >>>> ixl1: Using 1024 TX descriptors and 1024 RX descriptors >>>> ixl1: Using 12 RX queues 12 TX queues >>>> ixl1: Using MSI-X interrupts with 13 vectors >>>> ixl1: Ethernet address: a4:bf:01:76:ef:9b >>>> ixl1: Allocating 16 queues for PF LAN VSI; 12 queues active >>>> ixl1: SR-IOV ready >>>> ixl1: netmap queues/slots: TX 12/1024, RX 12/1024 >>>> ixl2: >>>> mem 0xb1000000-0xb1ffffff,0xb5008000-0xb500ffff at device 0.2 >>>> numa-domain 0 on pci6 >>>> ixl2: fw 3.1.55727 api 1.5 nvm 3.31 etid 80000d32 oem 1.262.0 >>>> ixl2: PF-ID[2]: VFs 32, MSI-X 129, VF MSI-X 5, QPs 384, I2C >>>> ixl2: Using 1024 TX descriptors and 1024 RX descriptors >>>> ixl2: Using 12 RX queues 12 TX queues >>>> ixl2: Using MSI-X interrupts with 13 vectors >>>> ixl2: Ethernet address: a4:bf:01:76:ef:9c >>>> ixl2: Allocating 16 queues for PF LAN VSI; 12 queues active >>>> ixl2: ixl_set_link: Error getting phy capabilities -7, aq error: 5 >>>> ixl2: SR-IOV ready >>>> ixl2: netmap queues/slots: TX 12/1024, RX 12/1024 >>>> ixl3: >>>> mem 0xb0000000-0xb0ffffff,0xb5000000-0xb5007fff at device 0.3 >>>> numa-domain 0 on pci6 >>>> ixl3: fw 3.1.55727 api 1.5 nvm 3.31 etid 80000d32 oem 1.262.0 >>>> ixl3: PF-ID[3]: VFs 32, MSI-X 129, VF MSI-X 5, QPs 384, I2C >>>> ixl3: Using 1024 TX descriptors and 1024 RX descriptors >>>> ixl3: Using 12 RX queues 12 TX queues >>>> ixl3: Using MSI-X interrupts with 13 vectors >>>> ixl3: Ethernet address: a4:bf:01:76:ef:9d >>>> ixl3: Allocating 16 queues for PF LAN VSI; 12 queues active >>>> ixl3: ixl_set_link: Error getting phy capabilities -7, aq error: 5 >>>> ixl3: SR-IOV ready >>>> ixl3: netmap queues/slots: TX 12/1024, RX 12/1024 >>>> ixl2: Link is up, 10 Gbps Full Duplex, Requested FEC: None, >>>> Negotiated FEC: None, Autoneg: False, Flow Control: None >>>> ixl2: link state changed to UP >>>> ixl3: Link is up, 10 Gbps Full Duplex, Requested FEC: None, >>>> Negotiated FEC: None, Autoneg: False, Flow Control: None >>>> ixl3: link state changed to UP >>>> bridge0: can't disable some capabilities on ixl3.15: 0x400 >>>> ixl3: promiscuous mode enabled >>>> ixl3.15: promiscuous mode enabled >>>> >>>> >>>> from my packet traces: >>>> >>>> # tcpdump -vvv -i ixl3 >>>> >>> May you please add the option -e to tcpdump, so that the link-level >>> header can be printed out. >>> >>> ``` >>> # tcpdump -nvei ixl3 >>> ``` >>> >>>> tcpdump: listening on ixl3, link-type EN10MB (Ethernet), capture >>>> size 262144 bytes >>>> [...] >>>> 13:36:20.155843 ARP, Ethernet (len 6), IPv4 (len 4), Request >>>> who-has 192.168.55.1 tell 192.168.55.10, length 28 >>>> 13:36:20.156285 ARP, Ethernet (len 6), IPv4 (len 4), Reply >>>> 192.168.55.1 is-at b8:27:eb:47:8f:43 (oui Unknown), length 46 >>>> 13:36:21.169003 ARP, Ethernet (len 6), IPv4 (len 4), Request >>>> who-has 192.168.55.1 tell 192.168.55.10, length 28 >>>> 13:36:21.169538 ARP, Ethernet (len 6), IPv4 (len 4), Reply >>>> 192.168.55.1 is-at b8:27:eb:47:8f:43 (oui Unknown), length 46 >>>> >>>> Here the answer can be see, its tagged with 802.1q tag 15 >>>> >>>> >>>> # tcpdump -vvv -i ixl3.15 >>>> tcpdump: listening on ixl3.15, link-type EN10MB (Ethernet), capture >>>> size 262144 bytes >>>> 14:14:37.255429 ARP, Ethernet (len 6), IPv4 (len 4), Request >>>> who-has 192.168.55.1 tell 192.168.55.10, length 28 >>>> 14:14:42.263475 ARP, Ethernet (len 6), IPv4 (len 4), Request >>>> who-has 192.168.55.1 tell 192.168.55.10, length 28 >>>> 14:15:02.556311 ARP, Ethernet (len 6), IPv4 (len 4), Request >>>> who-has 192.168.55.1 tell 192.168.55.10, length 28 >>>> 14:15:07.557644 ARP, Ethernet (len 6), IPv4 (len 4), Request >>>> who-has 192.168.55.1 tell 192.168.55.10, length 28 >>>> >>>> The answer cannot be seen on the VLAN interface ): >>>> >>>> >>>> I hope the list can help me out here, as I am lost. >>>> >>>> >>>> Thanks & best >>>> >>>> >>>> Daniel >>>> >>> >>> Best regards, >>> Zhenlei >>> --------------h3cIX2ZczcxnZIWUnT9s5GDd Content-Type: text/html; charset=UTF-8 X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit

Hi Santi,


yes that was one of the first things i tried, disabling all the VLAN_HW* options on the interface, unfortunately without any change in the behavior.

The pf module is loaded and some filters are active on another interface but no filtering happens on ixl3, ixl3.15 or bridge0. That was also one of the reasons why I crosschecked my setup with an USB nic so I can make sure its not the firewall by accident.


Thanks & Best

Daniel


On 1/25/24 22:10, Santiago Martinez wrote:
Hi Daniel, 

have you try disabling hardware vlan filtering?

Also I guess there is not ipfw or pf modules loaded right?

Best 
Santi

On 25 Jan 2024, at 10:07, Daniel <freebsd-net@c0decafe.de> wrote:



Hi,

thanks for your suggestion. Turns out, when i unplug the vlan interface from the bridge and put the ip address on the vlan interface, as you suggested, things start to work, e.g. arp resolves.

as soon as i put the ip and the vlan interface back on the bridge, things stop again. so where does this lead me? the problem is not in the vlan handling, but on the bridge?

I started playing with the net.link.bridge sysctls and indeed, when i set


# sysctl net.link.bridge.inherit_mac=1


and then recreate the bridge


# ifconfig bridge0 deletem ixl3.15 deletem vnet0.1
# ifconfig bridge0 addm ixl3.15 addm vnet0.1


with the ip address still on bridge0 and ixl3, ixl3.15 and bridge0 all sharing the same mac address, arp starts resolving. but only for requests sent from the bridge0 interface. inside of the jail things still don't work (as the vnet interface again has another mac address).


# ifconfig ixl3
ixl3: flags=28963<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=4a500b9<RXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,NOMAP>
        ether a4:bf:01:76:ef:9d
        media: Ethernet autoselect (10Gbase-SR <full-duplex>)
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
# ifconfig ixl3.15
ixl3.15: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=4200001<RXCSUM,RXCSUM_IPV6,NOMAP>
        ether a4:bf:01:76:ef:9d
        groups: vlan
        vlan: 15 vlanproto: 802.1q vlanpcp: 0 parent interface: ixl3
        media: Ethernet autoselect (10Gbase-SR <full-duplex>)
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
# ifconfig bridge0
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether a4:bf:01:76:ef:9d
        inet 192.168.55.20 netmask 0xffffff00 broadcast 192.168.55.255
        id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
        maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
        root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
        member: vnet0.1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 9 priority 128 path cost 2000
        member: ixl3.15 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 8 priority 128 path cost 2000
        groups: bridge
        nd6 options=9<PERFORMNUD,IFDISABLED>
# ping 192.168.55.1
PING 192.168.55.1 (192.168.55.1): 56 data bytes
^C
--- 192.168.55.1 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss

[! yes, the host does not answer on ICMP, but that is to be expected !]

# arp -an
? (192.168.55.20) at a4:bf:01:76:ef:9d on bridge0 permanent [bridge]
? (192.168.55.1) at b8:27:eb:47:8f:43 on bridge0 expires in 1197 seconds [bridge]
[...]

[! into the jail !]

JAIL # ifconfig epair0b
epair0b: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=8<VLAN_MTU>
        ether ac:16:2d:bd:b7:34
        hwaddr 02:51:73:d1:33:0b
        inet 192.168.55.10 netmask 0xffffff00 broadcast 192.168.55.255
        inet6 fe80::ae16:2dff:febd:b734%epair0b prefixlen 64 scopeid 0x2
        groups: epair
        media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
        status: active
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
JAIL # ping 192.168.55.1
PING 192.168.55.1 (192.168.55.1): 56 data bytes
^C
--- 192.168.55.1 ping statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss
JAIL # arp -an
? (192.168.55.10) at ac:16:2d:bd:b7:34 on epair0b permanent [ethernet]
? (192.168.55.1) at (incomplete) on epair0b expired [ethernet]


I conclude that there must be some mac address filtering going on in the data path, whether its on ixl or the bridge.

In dmesg I also see:

>> bridge0: can't disable some capabilities on ixl3.15: 0x400

but as of /usr/src/sys/net/if.h:233 this maps to IFCAP_LRO which afaik should not have any influence on L2 filtering.


Have to say, I'm out of ideas again. Never had something like this. So far just 'throwing interfaces on a bridge' worked in the past. Any ideas where to look next?


Thanks a lot & best


Daniel


On 1/25/24 08:22, Zhenlei Huang wrote:


On Jan 23, 2024, at 11:03 PM, Daniel <freebsd-net@c0decafe.de> wrote:

Hi List,


just recently I discovered a problem with the ixl(4) driver. Hopefully someone here can help me. my setup is as follows:


Network ----- ixl3 interface ----- ixl3.15 vlan interface ----- bridge0 ----- vnet0.1 to jail


the problem now is that the jail can send data out (arp requests), i do see the responses on the ixl3 interface of the host, but they never make their way up to the ixl3.15 vlan interface (even though they are tagged correctly). To rule out that my config or the network is the cruel pit i did test the same setup with a cheap usb-ethernet adapter and there everything works as expected. I'm on FreeBSD 13.2-RELEASE-p8 and I did test both, the in kernel driver and the driver from ports intel-ixl-kmod-1.13.4_1.

I would encourage you to do plain VLAN tests, i.e. plug ixl3.15 out from bridge0

```
# ifconfig bridge0 deletem ixl3.15
# ifconfig bridge0 inet 192.168.55.20/24 delete ### to prevent confusion
# ifconfig ixl3.15 inet 192.168.55.x/24
# ping -c1 192.168.55.1
``` 


Here is a bit of information on my environment:

# uname -a
FreeBSD mimir 13.2-RELEASE-p8 FreeBSD 13.2-RELEASE-p8 GENERIC amd64

# pciconf -lBbcevV pci0:25:0:3
ixl3@pci0:25:0:3:       class=0x020000 rev=0x09 hdr=0x00 vendor=0x8086 device=0x37d3 subvendor=0x8086 subdevice=0x35d5
    vendor     = 'Intel Corporation'
    device     = 'Ethernet Connection X722 for 10GbE SFP+'
    class      = network
    subclass   = ethernet
    bar   [10] = type Prefetchable Memory, range 64, base 0xb0000000, size 16777216, enabled
    bar   [1c] = type Prefetchable Memory, range 64, base 0xb5000000, size 32768, enabled
    cap 01[40] = powerspec 3  supports D0 D3  current D0
    cap 05[50] = MSI supports 1 message, 64 bit, vector masks
    cap 11[70] = MSI-X supports 129 messages, enabled
                 Table in map 0x1c[0x0], PBA in map 0x1c[0x1000]
    cap 10[a0] = PCI-Express 2 endpoint max data 256(512) FLR RO
                 max read 512
                 link x1(x1) speed 2.5(2.5) ASPM disabled(L0s/L1)
    cap 03[e0] = VPD
    ecap 0001[100] = AER 2 0 fatal 0 non-fatal 1 corrected
    ecap 0003[140] = Serial 1 9aef76ffff01bfa4
    ecap 000e[150] = ARI 1
    ecap 0010[160] = SR-IOV 1 IOV disabled, Memory Space disabled, ARI disabled
                     0 VFs configured out of 32 supported
                     First VF RID Offset 0x006d, VF RID Stride 0x0001
                     VF Device ID 0x37cd
                     Page Sizes: 4096 (enabled), 8192, 65536, 262144, 1048576, 4194304
    ecap 0017[1a0] = TPH Requester 1
    ecap 000d[1b0] = ACS 1 Source Validation unavailable, Translation Blocking unavailable
                     P2P Req Redirect unavailable, P2P Cmpl Redirect unavailable
                     P2P Upstream Forwarding unavailable, P2P Egress Control unavailable
                     P2P Direct Translated unavailable, Enhanced Capability unavailable
  PCI-e errors = Correctable Error Detected
                 Unsupported Request Detected
     Corrected = Advisory Non-Fatal Error
    VPD ident  = 'Example VPD'

# ifconfig
[...]
ixl3: flags=8963<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=4a500b9<RXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,NOMAP>
        ether a4:bf:01:76:ef:9d
        media: Ethernet autoselect (10Gbase-SR <full-duplex>)
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
ixl3.15: flags=8942<BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=4200001<RXCSUM,RXCSUM_IPV6,NOMAP>
        ether a4:bf:01:76:ef:9d
        groups: vlan
        vlan: 15 vlanproto: 802.1q vlanpcp: 0 parent interface: ixl3
        media: Ethernet autoselect (10Gbase-SR <full-duplex>)
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 58:9c:fc:10:dd:05
        inet 192.168.55.20 netmask 0xffffff00 broadcast 192.168.55.255
        id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
        maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
        root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
        member: vnet0.1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 9 priority 128 path cost 2000
        member: ixl3.15 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 8 priority 128 path cost 55
        groups: bridge
        nd6 options=9<PERFORMNUD,IFDISABLED>
[...]



# cat /etc/rc.conf
[...]
ifconfig_ixl3="up"
vlans_ixl3="15"
cloned_interfaces="bridge0"
ifconfig_bridge0="addm ixl3.15 up"
[...]



# dmesg | grep ixl
ixl0: <Intel(R) Ethernet Connection X722 for 10GBASE-T - 2.3.3-k> mem 0xb3000000-0xb3ffffff,0xb5018000-0xb501ffff at device 0.0 numa-domain 0 on pci6
ixl0: fw 3.1.55727 api 1.5 nvm 3.31 etid 80000d32 oem 1.262.0
ixl0: PF-ID[0]: VFs 32, MSI-X 129, VF MSI-X 5, QPs 384, MDIO shared
ixl0: Using 1024 TX descriptors and 1024 RX descriptors
ixl0: Using 12 RX queues 12 TX queues
ixl0: Using MSI-X interrupts with 13 vectors
ixl0: Ethernet address: a4:bf:01:76:ef:9a
ixl0: Allocating 16 queues for PF LAN VSI; 12 queues active
ixl0: SR-IOV ready
ixl0: netmap queues/slots: TX 12/1024, RX 12/1024
ixl1: <Intel(R) Ethernet Connection X722 for 10GBASE-T - 2.3.3-k> mem 0xb2000000-0xb2ffffff,0xb5010000-0xb5017fff at device 0.1 numa-domain 0 on pci6
ixl1: fw 3.1.55727 api 1.5 nvm 3.31 etid 80000d32 oem 1.262.0
ixl1: PF-ID[1]: VFs 32, MSI-X 129, VF MSI-X 5, QPs 384, MDIO shared
ixl1: Using 1024 TX descriptors and 1024 RX descriptors
ixl1: Using 12 RX queues 12 TX queues
ixl1: Using MSI-X interrupts with 13 vectors
ixl1: Ethernet address: a4:bf:01:76:ef:9b
ixl1: Allocating 16 queues for PF LAN VSI; 12 queues active
ixl1: SR-IOV ready
ixl1: netmap queues/slots: TX 12/1024, RX 12/1024
ixl2: <Intel(R) Ethernet Connection X722 for 10GbE SFP+ - 2.3.3-k> mem 0xb1000000-0xb1ffffff,0xb5008000-0xb500ffff at device 0.2 numa-domain 0 on pci6
ixl2: fw 3.1.55727 api 1.5 nvm 3.31 etid 80000d32 oem 1.262.0
ixl2: PF-ID[2]: VFs 32, MSI-X 129, VF MSI-X 5, QPs 384, I2C
ixl2: Using 1024 TX descriptors and 1024 RX descriptors
ixl2: Using 12 RX queues 12 TX queues
ixl2: Using MSI-X interrupts with 13 vectors
ixl2: Ethernet address: a4:bf:01:76:ef:9c
ixl2: Allocating 16 queues for PF LAN VSI; 12 queues active
ixl2: ixl_set_link: Error getting phy capabilities -7, aq error: 5
ixl2: SR-IOV ready
ixl2: netmap queues/slots: TX 12/1024, RX 12/1024
ixl3: <Intel(R) Ethernet Connection X722 for 10GbE SFP+ - 2.3.3-k> mem 0xb0000000-0xb0ffffff,0xb5000000-0xb5007fff at device 0.3 numa-domain 0 on pci6
ixl3: fw 3.1.55727 api 1.5 nvm 3.31 etid 80000d32 oem 1.262.0
ixl3: PF-ID[3]: VFs 32, MSI-X 129, VF MSI-X 5, QPs 384, I2C
ixl3: Using 1024 TX descriptors and 1024 RX descriptors
ixl3: Using 12 RX queues 12 TX queues
ixl3: Using MSI-X interrupts with 13 vectors
ixl3: Ethernet address: a4:bf:01:76:ef:9d
ixl3: Allocating 16 queues for PF LAN VSI; 12 queues active
ixl3: ixl_set_link: Error getting phy capabilities -7, aq error: 5
ixl3: SR-IOV ready
ixl3: netmap queues/slots: TX 12/1024, RX 12/1024
ixl2: Link is up, 10 Gbps Full Duplex, Requested FEC: None, Negotiated FEC: None, Autoneg: False, Flow Control: None
ixl2: link state changed to UP
ixl3: Link is up, 10 Gbps Full Duplex, Requested FEC: None, Negotiated FEC: None, Autoneg: False, Flow Control: None
ixl3: link state changed to UP
bridge0: can't disable some capabilities on ixl3.15: 0x400
ixl3: promiscuous mode enabled
ixl3.15: promiscuous mode enabled


from my packet traces:

# tcpdump -vvv -i ixl3

May you please add the option -e to tcpdump, so that the link-level header can be printed out.

```
# tcpdump -nvei ixl3
```

tcpdump: listening on ixl3, link-type EN10MB (Ethernet), capture size 262144 bytes
[...]
13:36:20.155843 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.55.1 tell 192.168.55.10, length 28
13:36:20.156285 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.55.1 is-at b8:27:eb:47:8f:43 (oui Unknown), length 46
13:36:21.169003 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.55.1 tell 192.168.55.10, length 28
13:36:21.169538 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.55.1 is-at b8:27:eb:47:8f:43 (oui Unknown), length 46

Here the answer can be see, its tagged with 802.1q tag 15


# tcpdump -vvv -i ixl3.15
tcpdump: listening on ixl3.15, link-type EN10MB (Ethernet), capture size 262144 bytes
14:14:37.255429 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.55.1 tell 192.168.55.10, length 28
14:14:42.263475 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.55.1 tell 192.168.55.10, length 28
14:15:02.556311 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.55.1 tell 192.168.55.10, length 28
14:15:07.557644 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.55.1 tell 192.168.55.10, length 28

The answer cannot be seen on the VLAN interface ):


I hope the list can help me out here, as I am lost.


Thanks & best


Daniel


Best regards,
Zhenlei

--------------h3cIX2ZczcxnZIWUnT9s5GDd-- From nobody Mon Jan 29 11:49:41 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 4TNmn35YtDz58Yp0 for ; Mon, 29 Jan 2024 11:49:43 +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 4TNmn34WvNz43G5 for ; Mon, 29 Jan 2024 11:49:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706528983; 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=NEL1tRRCIfoMBT5xZF4vEc/iJiohRc/NW/KMjvhVo5o=; b=HqaXdZm+UMBuqOkERyKAR7sPVImmWDvFa5yjhlcwjZ1s3y1Yi0DcOTE2jUYojN5fUVuIFD KLCgQBRVYqNYvm02RkOaonZXzuidN7PBKUPRI/b7eyJ4cKD77K+40so+lpXvI/vyTg4+C4 yTsXDNnElnYdAzMcYRimGXWpiDNT4OueNK+zp7CeM2b8qPaaGsryCemc0XUZq32kF8P3W+ RJikB1BI7o/QVFekdr0iAXn+Owsn3mTzUbsa6y5b3KEtGixV5xhT/Enxb+TZCnYRAkt1Sg iL41/UUmt40imFp/i2I+/H9/ELi5f2TzvcDz0V+iM8VyT1AVBqoScWXUlrHrBg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706528983; a=rsa-sha256; cv=none; b=twv3yTE1+b3T4XMTd+it0BuVtoqFFqAWSPVjDI6xIzLI0/y6X5qoCKPZlZ462QSKZpnpm4 84AfFrqJTJ80U7x7jSkd641WTRSND/LawpZQ9mMV67umjXttTxuPT47CKhnj3ClLOk4hcF 5u1uhI1cJc3j8YkRFKOByPayL0AxZql9lIkxohdk6PjRtodTP+ZaUyxgOrmA7+acBq4Yfz herp/tsULNQiAgc0QsBJ+9R4iKBILsAIz7O8oE9TtIEbFPTW2QFvGbNfnRLE5VZPMfPQft dJH5a32M3BVanz7szgFuPXXa2RlkgFRkK7BLpsCobzm50IdhUHamK7W5a9Ey6Q== 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 4TNmn33Zy7zq2H for ; Mon, 29 Jan 2024 11:49:43 +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 40TBnhic027263 for ; Mon, 29 Jan 2024 11:49:43 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 40TBnhAZ027254 for net@FreeBSD.org; Mon, 29 Jan 2024 11:49: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 165059] vtnet(4): Networking breaks with a router using virtio net driver on KVM host Date: Mon, 29 Jan 2024 11:49:41 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.0-RELEASE X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: 10@3it.ru X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? mfc-stable13? mfc-stable12? 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=3D165059 Igor Raschetov <10@3it.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |10@3it.ru --- Comment #32 from Igor Raschetov <10@3it.ru> --- Hello Adding parameters to /boot/loader.conf hw.vtnet.X.tso_disable=3D"1" hw.vtnet.tso_disable=3D"1" hw.vtnet.lro_disable=3D"1" hw.vtnet.X.lro_disable=3D"1" hw.vtnet.csum_disable=3D"1" hw.vtnet.X.csum_disable=3D"1" Solved the problem --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Tue Jan 30 05:39:47 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 4TPDWl3dWmz58L1l for ; Tue, 30 Jan 2024 05:39:47 +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 4TPDWl1tM3z4Wk4 for ; Tue, 30 Jan 2024 05:39:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706593187; 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=WfLTZRcRoAsgCkT7EV1iRFptvBvMjlo0Vzvg5J2atak=; b=OpPx1XmaV9PCDfsPIknVZqW8IkZfprZiOsrK6SfYtU8dM0ObMfH3RdsAUNGi5m7BR+7bOn RwF/TThUjB0cPGHyao7cRNSBNYpj+CFjRUBVHLe2wk5WdobckNWqz0OFw/Fb6E2QhrRVwh ELOCz6WaJ+p58t6yDOzlxkIMF3xmK0hrWSMA4ar83MbNhtmKPx4uqffTBjT2Ur7wuyZLV9 Kqbn5D9/kPesJxDG4VnyJDbGcUGKZhQnR9VlmB+dlSMFE18F/W08N1TCpTXyxq2usgssYO 8hE4L6NiVicxDzeHZj0YmLjZKQgWZM/vFdcSYpwWDBtLMy0Zmmb46lFqKSb1TA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706593187; a=rsa-sha256; cv=none; b=S0xiYmDdZszo+ql0ZbcLO1R1BIqbOJ9cMfp/5yXAAy44ZWVZBr3+fW0Br4hlEQ35zie3nh 6fn7eJRxga7z8QTxFqKf6vb61sB5iR4DuoZUNcFBaT8LTZfs1pDVvZe24dCieUDzRS1uGz S/VmZ46UGk2M5lyiRxNk23ct4lSsDH6TzNNaxCukssdILxippyP7kz/nbNRu4ETwIoWPXP sR5uI0pDy7/e6q4C9FCLURp3r/0hnlG6w2odk+RoMorA2quCX9saKACJnSeQLKZWZ5uVi1 76aF6NlIQcVvTmqgYrLnEsEE/glhHkDk9jujsr8BVng+JaAJheNacje2Wj9pRg== 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 4TPDWl0Z4pzN64 for ; Tue, 30 Jan 2024 05:39:47 +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 40U5dl7Y062632 for ; Tue, 30 Jan 2024 05:39:47 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 40U5dlel062631 for net@FreeBSD.org; Tue, 30 Jan 2024 05:39:47 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 276363] if_wg: Fix bug in calculate_padding() for the 'p_mtu = 0' case Date: Tue, 30 Jan 2024 05:39:47 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kevans@freebsd.org X-Bugzilla-Flags: mfc-stable14? mfc-stable13? mfc-stable12- 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=3D276363 --- Comment #6 from commit-hook@FreeBSD.org --- A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3D86986d381072171a5d6183701ae2f96c2= d9a6406 commit 86986d381072171a5d6183701ae2f96c2d9a6406 Author: Aaron LI AuthorDate: 2024-01-17 23:29:23 +0000 Commit: Kyle Evans CommitDate: 2024-01-30 05:37:29 +0000 if_wg: fix erroneous calculation in calculate_padding() for p_mtu =3D= =3D 0 In practice this is harmless; only keepalive packets may realistically = have p_mtu =3D=3D 0, and they'll also have no payload so the math works out = the same either way. Still, let's prefer technical accuracy and calculate the amount of padding needed rather than the padded length... PR: 276363 (cherry picked from commit b891f61ef538a4e9b4658b4b756635c8036a5788) sys/dev/wg/if_wg.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Tue Jan 30 05:39: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 4TPDWf5kTZz58L3K for ; Tue, 30 Jan 2024 05:39:42 +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 4TPDWf1nRsz4Wjx for ; Tue, 30 Jan 2024 05:39:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706593182; 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=R4R8vll8ofolEKUr+Q1UugRMtQ57q08y5AKjXnp6lzY=; b=uTYkqp0I132K8pTqJCLzzgN0W+hwKBEOLJWzsnTkqDJr7+80wp5e9R3ORk4lTWxL0/WjFf KmqjWvB7Ao16Si1CPg1d9WyKWolc0z9Y3x+RcQbEAFchCDBt+AI/ReA644gam0RBztseCB vZZ6IF51cA99olEQV6X+8QqlUDyxc9n3E+YMPgy0WmWsnMPMo6My7OqNorNCrZykvPbxCB Sf5ogVAY9oS6P9G1BWdNkmuIf7F8aP+YmIzLznQTFd5D/vThjLL/dcxPkaEs4Yco3E3Btf 7G0bxLpZxYF91F7YUrTYKkavfgujTWXT/OwZkRkU7Nk6SzuonhrKC7zewPuKFg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706593182; a=rsa-sha256; cv=none; b=XUfGL8kkKI2Ip2CCG42q4m9FeARaE9v5QijpHqwYKC76IGqE8YQUTN8kNkQOUUZJihXMsq V4aZTuUDX2lpXQOj0afQQpNdSM5RpDr2lyvXKTG4sPNzT5Jeo68YmRgEQH1XMtyYFb8N9w vbNOmbtclTiQBo3p6fCmH2pP5TQaXdYQmPM+KSiSSYw9WtWOzRsBLpyvgGw9h14XTA2maM ET4gD69ZXnuODjETJkx1hVBXqHAys/isB/zRu9BwMv3DY4tZQf3pYr0m6f9iRqh65J7R4E okaD9UmqgDB8Sq2nKCY6y055ZVVMpAP6QDGuClEyOcfufmrYMY5Sr+EyNtfH8A== 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 4TPDWf0pQ5zN60 for ; Tue, 30 Jan 2024 05:39:42 +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 40U5dgCX062268 for ; Tue, 30 Jan 2024 05:39:42 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 40U5dgoV062266 for net@FreeBSD.org; Tue, 30 Jan 2024 05:39:42 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 276392] if_wg: Fix noise_remote_alloc() to acquire 'l_identity_lock' lock Date: Tue, 30 Jan 2024 05:39:42 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kevans@freebsd.org X-Bugzilla-Flags: mfc-stable14? mfc-stable13? mfc-stable12- 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=3D276392 --- Comment #6 from commit-hook@FreeBSD.org --- A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3Dce2d249b207045f27ec03719997168c92= d0f6104 commit ce2d249b207045f27ec03719997168c92d0f6104 Author: Aaron LI AuthorDate: 2024-01-17 23:29:23 +0000 Commit: Kyle Evans CommitDate: 2024-01-30 05:37:57 +0000 if_wg: fix access to noise_local->l_has_identity and l_private These members are protected by the identity lock, so rlock it in noise_remote_alloc() and then assert that we have it held to some extent in noise_precompute_ss(). PR: 276392 (cherry picked from commit 7a4d1d1df0b2e369adcb32aea9ef8c180f885751) sys/dev/wg/wg_noise.c | 4 ++++ 1 file changed, 4 insertions(+) --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Tue Jan 30 05:39:45 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 4TPDWj6lShz58LH6 for ; Tue, 30 Jan 2024 05:39: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 4TPDWj4bC3z4Wc5 for ; Tue, 30 Jan 2024 05:39:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706593185; 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=+ilaX0hA+zmzb3iHTXRvVw+L/Ig7kTraU9C27ow+uW0=; b=MtkiYjCbq6G6TRU2UDfkeLdKvaz02SPHG5x2tWtLFHvAhLgwpV6yuMpMONIFlK7FyBwATC 4fn2efv9spcSDwXfgrdOKiHfydlv0qu3onGD01Z3k68upF6O1JJlD2H4+3OZrgFAAlP4KZ YLolj71NUopxTUZ0a7PRjFnAjAdKDcd6HIC/jbR7EabgxLNv+2of7X//XU0ARKyZBm/wUy xgmxeBZJb83KQhe23nnwE1LaTeG3mRHAc+WRxshAuAzxHLnpfl+i++0XyEbtZGFa4VCLZd pCSKP46iswKnDgEeVU/M7dM3MhSMwOMFTO7/RP9sSe8SJnTyUz2ILBGcKbGrLw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706593185; a=rsa-sha256; cv=none; b=d1Uj3IUXPXWPiXCVLguzpcaA2FcDv5yiQH7R/yJxp+2fepBKvZSDXfOvcgNfebbOS7qf58 Qv+FXWu0yLaT206xF5iUcS3iVpvk1VmLsKBs52D27XDhiY3QwiXMQXvv0evtQr8pCTAErc 6n3hvZ9lUDR5W+ktHBa7+Z9daSFCIoYiMLYH3yc/qcE2SFruhL3C3xSwX/mfq4dQ9m3xfC 6rB+Lokz3GJS6ymGwhNCpfQ9lKypviY273FBTT06BP5AF7TQjLsaWm51UfSPG3JzIkfdIP 39dJyCHVDmlDcKCDWc/aBPrehCCfcwKAuWwfU954GXlvT+LWATIvZVzKF1aNFg== 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 4TPDWj3YM5zN7w for ; Tue, 30 Jan 2024 05:39:45 +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 40U5djlp062482 for ; Tue, 30 Jan 2024 05:39:45 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 40U5djBB062477 for net@FreeBSD.org; Tue, 30 Jan 2024 05:39:45 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 276363] if_wg: Fix bug in calculate_padding() for the 'p_mtu = 0' case Date: Tue, 30 Jan 2024 05:39:45 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kevans@freebsd.org X-Bugzilla-Flags: mfc-stable14? mfc-stable13? mfc-stable12- 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=3D276363 --- Comment #5 from commit-hook@FreeBSD.org --- A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3Dbbda52e814e0c760b2beaeae40a2c76ff= 43d1975 commit bbda52e814e0c760b2beaeae40a2c76ff43d1975 Author: Aaron LI AuthorDate: 2024-01-17 23:29:23 +0000 Commit: Kyle Evans CommitDate: 2024-01-30 05:37:46 +0000 if_wg: fix erroneous calculation in calculate_padding() for p_mtu =3D= =3D 0 In practice this is harmless; only keepalive packets may realistically = have p_mtu =3D=3D 0, and they'll also have no payload so the math works out = the same either way. Still, let's prefer technical accuracy and calculate the amount of padding needed rather than the padded length... PR: 276363 (cherry picked from commit b891f61ef538a4e9b4658b4b756635c8036a5788) sys/dev/wg/if_wg.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Tue Jan 30 05:39:49 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 4TPDWn4jFCz58L8C for ; Tue, 30 Jan 2024 05:39:49 +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 4TPDWn2bfxz4WmK for ; Tue, 30 Jan 2024 05:39:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706593189; 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=lgbVxbasrCU5knHT/qr7hJoYcDkWTDl9wXwxLZgX2ks=; b=NLJEbuKG+hY+oBQHhse4sdV1riDDCa2zXYYs+kxKQ/1iV2BrBbeeoezIyVMSrXxjNsNfLY iPx7cF4XRAzSvy34htHDIFbcuwcWxfcGrCkw6wWL17GUahaQq3sgpYDLvl65wSx3DCyTUn 5183N3QHlYtCiH6LUI1LopLHojYm0frq5dzu0HaccuBUGGgvp79fQz19YFpGh/JRoFtusB WTERaeRNZ1Gcd8Qk73h9tPVHXRak26jP+VO/nASzvpmFvA8ckHzVhHUMogZG8P5oPH+CUR s6Se1t4ElqWUrfjHWifXt8FamAvuCbFz0czt96JARKu4mnGYNE6NWle6VebMBA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706593189; a=rsa-sha256; cv=none; b=m/xQORMHGFe/iJI+R4ssIjXww2ssFDjkEwKWbQXkeGUmf/vDu8vvBsNkcsDvK2fEDKyXgk 2j0HBE1n19jOX8nnZRvTmgx7svhn8/qoglb5ZzKM/KbB/hz+uga6Rrn7NUeLYC+i3kK1k3 KHvR2rF8zCJCdwRghZSk3Yw68SUwwkETv9YOFJ+g6dd5Ug1R1prCb2XZOs0mY7UtvsqL2x 7ZXMpVhQz3TJWeKDoJsHGUkVMfIKe8oG4AFqcjevrqjnpaho9yaC1gpBQTWG9lRSB4xOne sBMDVIqWrxDUZYkK5e1acgrxb/+IYyxXWOmey/2m0iHqhDZQR+wMNPih+4ztXg== 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 4TPDWn1MvWzNYR for ; Tue, 30 Jan 2024 05:39:49 +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 40U5dnUr062748 for ; Tue, 30 Jan 2024 05:39:49 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 40U5dnOS062742 for net@FreeBSD.org; Tue, 30 Jan 2024 05:39:49 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 276392] if_wg: Fix noise_remote_alloc() to acquire 'l_identity_lock' lock Date: Tue, 30 Jan 2024 05:39:49 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kevans@freebsd.org X-Bugzilla-Flags: mfc-stable14? mfc-stable13? mfc-stable12- 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=3D276392 --- Comment #7 from commit-hook@FreeBSD.org --- A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3Db0fa37f356fd9dd5040c034c7523ec235= fbb311b commit b0fa37f356fd9dd5040c034c7523ec235fbb311b Author: Aaron LI AuthorDate: 2024-01-17 23:29:23 +0000 Commit: Kyle Evans CommitDate: 2024-01-30 05:37:33 +0000 if_wg: fix access to noise_local->l_has_identity and l_private These members are protected by the identity lock, so rlock it in noise_remote_alloc() and then assert that we have it held to some extent in noise_precompute_ss(). PR: 276392 (cherry picked from commit 7a4d1d1df0b2e369adcb32aea9ef8c180f885751) sys/dev/wg/wg_noise.c | 4 ++++ 1 file changed, 4 insertions(+) --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Tue Jan 30 05:47: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 4TPDhg4024z58Lfn for ; Tue, 30 Jan 2024 05:47: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 4TPDhf6nvYz4cnl for ; Tue, 30 Jan 2024 05:47:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706593651; 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=aK8ziKrwSL9VoYxxhNtfWo7uzqROD/VsXZnwrYAhR2I=; b=py7WZIdTGZ1IywrwsPkA+lWqZ78Z2kUgUMIbuBZdEKl2TYWuzNsSft/bNTOvrq+9c4T7jt 8Bwt2GaN0n9GSm3tvovDJbHiqVAUtCSBenIkv5eGPprgRtETj+AfgvfKtb9CzZwljKblTU fd+lBvDg9Xc57cQyo2kWhM+m7hE2YU+dddZD/5w1u6ilEZu78M721nFL0evF3viimbszV1 9EUyEsHwknR3S+YoTD19+RolUWX6bee3AOs5YdWYvX/iKByoolK48b9NqtgwNKUi5+YvT6 s7u7xqnPhzaRHr6uJKv2Esw0jpcoQy/UfHkeEhxDNdZmMktCSFbeZbAZPcI5Jw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706593651; a=rsa-sha256; cv=none; b=B0pAAqRatxBxmVep6StGfMVFOy5QGQ+lLdvIMkuf5Iqq56vNuf2oju0FhGjWlFqEmvzK8V R4vp777KzzfK7mX2RMIL9qHgcTis6R5hxRftqASiloDlh2E5rlN0ARVXzJY8tpxD6pPBxQ ued1EXUVuotoLpsG9Eh4rm9il93+Z46TfJ4DIWTwdoldEkZQLrOp6MddpAbiHby7VIrgYa zwN9VFm2YJsC3eyFN6mk2E39I7ByegFJJToqn2s9cirLFLY3/UA+wa/4XbrICO3k5A//wp kai7oGI1gSICe6v0jD5deWXPvmjbYFZrvjNxYkFQmkVBTjhWsrMk4dugAmKJpw== 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 4TPDhf5lsYzNpg for ; Tue, 30 Jan 2024 05:47:30 +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 40U5lUMu004606 for ; Tue, 30 Jan 2024 05:47:30 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 40U5lUuV004605 for net@FreeBSD.org; Tue, 30 Jan 2024 05:47: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 276392] if_wg: Fix noise_remote_alloc() to acquire 'l_identity_lock' lock Date: Tue, 30 Jan 2024 05:47:30 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: kevans@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kevans@freebsd.org X-Bugzilla-Flags: mfc-stable14+ mfc-stable13+ mfc-stable12- X-Bugzilla-Changed-Fields: resolution flagtypes.name bug_status 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=3D276392 Kyle Evans changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Flags|mfc-stable14?, |mfc-stable14+, |mfc-stable13? |mfc-stable13+ Status|In Progress |Closed --- Comment #8 from Kyle Evans --- MFC'd to all supported branches; thanks! --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Tue Jan 30 05:47:41 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 4TPDht39Pdz58Lqy for ; Tue, 30 Jan 2024 05:47:42 +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 4TPDht1dvbz4cZF for ; Tue, 30 Jan 2024 05:47:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706593662; 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=ysxhq4YUDDLSIzdqknZ9so/+JCUd+j0Uru6JuM1bPwU=; b=ZTazUMaeyVESun55Rf+OV+76xSTy2DrjsbqjxsciO6HPfAjMoJus4x2DGLeMIzTmYjjbMS kOVXaYOSEpiePfTkbp7Xs/JoJ29ynNM2c4gqGfHgGktG+KmnzyYCCEDX+coNuTxsJbLshM f3tJGTTimToOWq25dIzvCUHc3LKP6EXvA4gdJfp8mUuOfbVr1gJemC+2+ZmbyGdQpfDK3u V2qZc1cgX22AoAo8kCgS//LoKuravCUL5gSHSV0nTDfcOO33Cp/nmlddfpEMiT2bo42HA9 0FXAEPNIlfNQriAJmbZOVA6x+Ud3gtuTN1BnPSeI4p0XPYrBmh37VHwNDipCTg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706593662; a=rsa-sha256; cv=none; b=an46cXatuQVGaQUDfcH4EAazUcFQOduo8EYnQ+315vrnnEoJUlUrycS0VPLf86iI0K2oct 8wcBCO3386Wu3CUPlIJPus/4Say1wNe/Q/ohS6Shix2HNlySVZTnv4XCcFNb3O/A5xoMlU Bn4dWTnugU7xo9R4z3SVUeN8KGt8iqTU8mD6L3iOBg4VDgjYdfBqnlUjHv3bKcvi0UMKqR O95B6zyGfnUXFqQ85N2U7h+c4ht7Me8e5nQ1gRKmlie9nuy3z/LUOCw07bMzjLznAAHlNa wV7LTZzMQ1S+ZIKJHqtX+WX9YaqB/VLNuSgcqfnOxPLRxpK42aisXnCKOmITuw== 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 4TPDht0YmnzNpl for ; Tue, 30 Jan 2024 05:47:42 +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 40U5lgdH005198 for ; Tue, 30 Jan 2024 05:47:42 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 40U5lg89005197 for net@FreeBSD.org; Tue, 30 Jan 2024 05:47:42 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 276526] if_wg: Add missing bpfdetach() in wg_clone_destroy() Date: Tue, 30 Jan 2024 05:47:41 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: kevans@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kevans@freebsd.org X-Bugzilla-Flags: mfc-stable14+ mfc-stable13+ X-Bugzilla-Changed-Fields: resolution bug_status flagtypes.name 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=3D276526 Kyle Evans changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|In Progress |Closed Flags|mfc-stable14?, |mfc-stable14+, |mfc-stable13? |mfc-stable13+ --- Comment #5 from Kyle Evans --- MFC'd to all supported branches; thanks! --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Tue Jan 30 05:47:56 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 4TPDj92lfpz58Lfp for ; Tue, 30 Jan 2024 05:47:57 +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 4TPDj906q2z4ccy for ; Tue, 30 Jan 2024 05:47:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706593677; 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=KaZOJ60gIF1q4QGPD2pM+vmVa6Tuv9i4Wqg20eJxtGc=; b=Oaz1c8hr7sRDJ+aO9scSW8afP4jxiog4EmowXpoGxNNH20oFJSAsTZsMxcnktqcUHj3ZVy DzjHNn1U58TPurPj0xPqolmd11tD6Z85kDYGxJ9qNQuXbL5UctfhxFaklQZ/L9eIr5r3V1 H5i9G++ZJLTkRFbLMOFFtRFLmEGvcwDdF/E47Abvb+L4DCiSA5t6aLYQY4L1C/PiypnRgm cwFqOIuptMcTO5WHlJFlzLIrNWM2BiAcuQaJX5rxinz6eWCm4o3Rh52wQmQbdGjQF6KKSH id/6NdmQFeYoz+pv2iFV9anlqK25HBReoZJStSPq5ass1P24pSwJrtOz5kbzuQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706593677; a=rsa-sha256; cv=none; b=hnL+uFCsx24udybgyqJJ2g1qt9fKBIdNWg8wSUI8EZ2TLGTz1ZL7RkH/RXQZ4d11iOkbv/ t9jXbDsY3/95JiqJVogqNu9Zo2oooPcK+CuLeK1/pda5TccbH3f9pDpV8QT8Qps9vbaqUK nfUb7tg3G1spERPG5/hzeDdKKZNeSvyfbAzdMdp3SGE88TnZMjf3iyNrpuhUlH7KugPRh6 qLVtbLrZFWkFBrdLCCso1KIEK8fDJhbVpR7enKRDqS9qWk8/nUtVvtKOThEgbtgGVzirYF M3IgFDEumY3zq5prd9ZCFb0AFwUq/C9uI3Jdmf/clNKvaRQVy8xtOYDrm6dEgA== 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 4TPDj84F8xzMxv for ; Tue, 30 Jan 2024 05:47:56 +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 40U5luLv005914 for ; Tue, 30 Jan 2024 05:47:56 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 40U5luhj005909 for net@FreeBSD.org; Tue, 30 Jan 2024 05:47:56 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 276363] if_wg: Fix bug in calculate_padding() for the 'p_mtu = 0' case Date: Tue, 30 Jan 2024 05:47:56 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: kevans@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kevans@freebsd.org X-Bugzilla-Flags: mfc-stable14+ mfc-stable13+ mfc-stable12- X-Bugzilla-Changed-Fields: resolution bug_status flagtypes.name 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=3D276363 Kyle Evans changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|In Progress |Closed Flags|mfc-stable14?, |mfc-stable14+, |mfc-stable13? |mfc-stable13+ --- Comment #7 from Kyle Evans --- MFC'd to all supported branches; thanks! --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Tue Jan 30 09:04:57 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 4TPK4V5z8Rz58RLn for ; Tue, 30 Jan 2024 09:04:58 +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 4TPK4V2cR9z42QM for ; Tue, 30 Jan 2024 09:04:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706605498; 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=5LglWYSQ2cQ/8t0gS88Yy1NWd3X/ifEIJAx4z6H2czM=; b=kUld8NMIlYbNXevVN8l7GePNLHOTuAr+FYEKx8uxQX6DnFCK+sUETlRbw16RytHONd7WjT PiGWGBY865w+cf6XFgnD0N32Pe2u29+ZkLaQZKaR5pQy7nUPyA1z96VzIPjteDKElWhZnN zzsZDxgOajAYvUADVf+gE+nCEp4+JsAz4QXXML+UqbZDtMm6kdcrB9LBAEvKcVViSV7i58 2etgXjdzsu27UgDaG21iBWihwG2sI7TmGNvN2BEdO0gTF7sao89JNyF2S0OxEW8KWOYMGV wtU5yBAss+BzQFQLad0n+X2ybMY9xYJ02SS2U/A2FHPe+MaWESVFqYjN8KYUqA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706605498; a=rsa-sha256; cv=none; b=WHspERUtcrdzIypkiT26PqWyVydhASrey+v7tBVLaeCQkmZ10wRgrtNPsIg5/IaCJWLvNF VnRvIie2Vz7y8JganxEBQDopFlXwdVHlCw679kSYzmQyUNHnkq6VoaJsNafUzJiucXOilp rFhvlItL/1au7HvGAUJLw/s/VTnAB0JsVGOIjx4GN9amyYLEmodNlR7HQWjKy5e7mYdWQG 8WeG8wYyNZXqgJsWPPJADIPzqQFlCFkZ7+KXs/OCOYun8U0Z3zSV0LZ1Jy7fSFUvkRZHtR OSUuVXDfIIHOEWJ88bFNtVLeUfNBmf61F6BGNLFLdbHNNYPzhXAb8v/cytmRrg== 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 4TPK4V1kWwzTRj for ; Tue, 30 Jan 2024 09:04:58 +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 40U94wlk028444 for ; Tue, 30 Jan 2024 09:04:58 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 40U94wJ6028443 for net@FreeBSD.org; Tue, 30 Jan 2024 09:04:58 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 276294] net/mpd5: crashes host when configured with PPPoE Date: Tue, 30 Jan 2024 09:04:57 +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: crash, needs-qa X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: eugen@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: keywords version component flagtypes.name assigned_to product 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=3D276294 Eugene Grosbein changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |crash, needs-qa Version|Latest |14.0-STABLE Component|Individual Port(s) |kern Flags|maintainer-feedback?(eugen@ |maintainer-feedback+ |freebsd.org) | Assignee|eugen@freebsd.org |net@FreeBSD.org Product|Ports & Packages |Base System --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Tue Jan 30 09:07:25 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 4TPK7L0NN4z58RdV for ; Tue, 30 Jan 2024 09:07:26 +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 4TPK7K4dLlz43SS for ; Tue, 30 Jan 2024 09:07:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706605645; 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=UflxmjQ/W5pJACAyqyRoSSPFD0maq+dHHBwBjsdEhQE=; b=G/PGlzGmuZ6KI7boZXqOrELfsXtyPAjEE1hCXkG80BjPKmJYTEq2auVhocNCjtxUDQUizG 0+QtZV27HOS55TCT5PqGJn9wBkIxjS5SDawVD4CrDiviUqImhJa9jtZaFAcpMYSSqKoAcx frYei15v/gnIS/MYeJPalV0lhbgF4hklgrlP6VxiyXK53i6ZU2/Yh+CsseMbMIDJHNOaTz oaAN19kY19g0n5bRh3mbrYuyifEBNZasLpS9u46y1aBb/vVtr/UVd6ZdKLFpUvVjTx/snK C/l7NEba6mtLu0jEMAEnc2/6GuEgDShZHlzm/TmWLmIvc+whklAcerJAqfw7uQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706605645; a=rsa-sha256; cv=none; b=YrdGdjGWwEcXSIUB3zCOOao5PCFihHC2SWHckLbRtC5ZzynZJdNvIysYY4peS5bqqoW4AX sOG83P70g7ENNHwtoIqHkOdMVPeolzkQWfpt0Y2064d5nCmJNg5BDf94dm7uotPE3xgD18 GYs/OPYMcqgUggOAJHgcOlY6VCjWO2vT/Ce4OPaBgLUTkH0sSOFWZ5LfILmaKtNg6iaZe0 PT8mq9YWAu/80IE57Rv8FN7rnn7dbhVcnQqOjfdNmUOM6QAQKSWs2GQKi5JDzQ2QUVjrER GCGrEMQsL+2MSzR03N49YdBnhwLUMUBhh85Xo3IzmYIDmBlI+ayrmYjY386O8A== 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 4TPK7K3Q7yzTfN for ; Tue, 30 Jan 2024 09:07:25 +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 40U97PN0036525 for ; Tue, 30 Jan 2024 09:07:25 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 40U97Pb4036524 for net@FreeBSD.org; Tue, 30 Jan 2024 09:07:25 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 276294] net/mpd5: crashes host when configured with PPPoE Date: Tue, 30 Jan 2024 09:07:25 +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: crash, needs-qa X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: eugen@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: bug_status 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=3D276294 Eugene Grosbein changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Open CC| |eugen@freebsd.org --- Comment #2 from Eugene Grosbein --- Sorry for late replay. Kernel panic means problem in FreeBSD base system (kernel part), as mpd5's own code is same for all supported branches. Can you collect crashdump? --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Wed Jan 31 15:02:00 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 4TQ4y13h3Pz58hZf for ; Wed, 31 Jan 2024 15:02:01 +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 4TQ4y10k0kz42Fp for ; Wed, 31 Jan 2024 15:02:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706713321; 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=RlJJUJc8gBtn/pJmMX6USpowBjVGQc01JxYip4dxt34=; b=mT2p8Eul0awJxzTuu2wP6j2l06/pFnAtKJWRqdxbXh/+vZZFHLVLbZAdRg+a+y/BMJmbms LWVpzjhGRZF/TinRjFaTBbAQXnVkrngly3BlGhSXdvbPFQDMhAPzEjUx8oGP450fwCnEbo 3y7h3hE1ZweVsD2e+mBPgE/qoaq4typMIiDVGkkT/HMdV93ce9IJrSQJfywmc1FD5NeKnq hXNirbw78sU8k2d2YGYmmFraIZ9XD8zT/5ArLX6HzZf1pz7SlDRy0xv8buE/lIZaFqXSlM gIoQgqXKkkWt/gY51mst28byaUJtQfezusHUfHUF1jxo9hvyJJwHqt8Mwhi3hA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706713321; a=rsa-sha256; cv=none; b=R+yHMqQLiFRFCKmjJaFcwud2ntE3lh2wY+5hW2lU1sHVge77FObOGNOnpBD8Q4Iwhwa+xH 45tY0MqoRQLrWDCigxNIU8lpCpXNRlmOzsUcKAE6DTADYnQPgQEbbJj6AunioD/BSucN3v Oh0aETCAfl881yPi2BcU4V1GFuULm9uWjCQNXLHGmRewawmzIL872W9LkULDn0IF38zC1E wzATwml+XeTTUOC3MSavKNIomquHXeFP/iIk9wrBoFpS8EBMEcVh5vw9RNGe7qtjAYIkEh B4EFmwwSMdo/LZuFxhafWtH+i2YH3Un9ujqSkLMaMOfbynyoy9qZ8ICjZH4M3w== 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 4TQ4y06wWGzMwc for ; Wed, 31 Jan 2024 15:02:00 +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 40VF20sX002681 for ; Wed, 31 Jan 2024 15:02:00 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 40VF20ow002663 for net@FreeBSD.org; Wed, 31 Jan 2024 15:02:00 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 274440] ice: ice0: Failed to set LAN Tx queue Date: Wed, 31 Jan 2024 15:02:00 +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: 13.2-RELEASE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: asomers@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events 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=3D274440 Alan Somers changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |Overcome By Events --- Comment #14 from Alan Somers --- Hearing no feedback from Intel for 3.5 months other than "we're working on = it", we finally removed the last E810-XXV-4 card and returned its server to production. So at this point we can't help debug the issue even if Intel s= hows up. Closing the bug. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Thu Feb 1 16:07: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 4TQkLq70hBz58vY7; Thu, 1 Feb 2024 16:07:15 +0000 (UTC) (envelope-from antranigv@freebsd.am) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (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 4TQkLp69Jwz4tbw; Thu, 1 Feb 2024 16:07:14 +0000 (UTC) (envelope-from antranigv@freebsd.am) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=freebsd.am header.s=fm2 header.b=arwJTWSR; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=Ta3AHeRU; dmarc=none; spf=pass (mx1.freebsd.org: domain of antranigv@freebsd.am designates 64.147.123.20 as permitted sender) smtp.mailfrom=antranigv@freebsd.am Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 9E73F3200B1B; Thu, 1 Feb 2024 11:07:13 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 01 Feb 2024 11:07:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.am; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:message-id:mime-version:reply-to :subject:subject:to:to; s=fm2; t=1706803633; x=1706890033; bh=I8 YTIycc5F2Xa1tQWaL91VCimu2G1EozsTBp3Qizlm0=; b=arwJTWSRJONrHOltfv T1Wu6qbiF6a8jNR8c/3BJmndIMiFm/BtVHER7M7uhoeIWhV589zVwEbMDHN3NND4 B4D68iAcp1l5DlyjMh0QXh/E3bXG45P8he0jMYhseN1LI8PU07ZiHAyBysy6zgTG kMjqZOSPSzdYNkj6o8Rj+SP8iA/01TPHsvAmPN/PThSQTEGnMP8kNSeBmaqfbC1N 5FG6iKdF/K4GCjnF9j+6e3EF2taBTxvaxG6tjIW9odGzZWzCrylSA0wn1ksjOosl 32xiYGKDxdGO2sjTUbYH7mpyrg/G+9zvdl1TMWp4hpoZb5aj5/Uz+o8YzxT+7uO1 qF2w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:message-id:mime-version:reply-to:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1706803633; x=1706890033; bh=I8YTIycc5F2Xa 1tQWaL91VCimu2G1EozsTBp3Qizlm0=; b=Ta3AHeRUXctk2+gI3l2g1Xwb5MCG9 Lru0cMvvOCx/VPM07CI+J0xfu+rtqlGBqUat7E8/BMhVCx7KQU+Pz5uk5kza4j0M nwKMpK2B1/EITu/+z3BFfcIX5MejA02U9mYCTDJVeNeXALjD4G0pCIt9HaIQhgz/ x2om+zX8PtGH9RGKl/4NY+/irIfKhOa+xzS62w7zMhUEaL962iCzELP/JdxOedR+ 6CBbfYmIqr0agLYh602+qPSKeQKpllyQZH1AGzAKgYeVXxF0kvdyhRB0hul77iiT EkZA8SIiPH7EA9pEgHlZOhFH8AUS3leWUdW9v9OXGFGjdhQn7/9qwZ+Vg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrfeduuddgkeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhtgfgggfukfffvefvofesthhqmh dthhdtjeenucfhrhhomheptehnthhrrghnihhgucggrghrthgrnhhirghnuceorghnthhr rghnihhgvhesfhhrvggvsghsugdrrghmqeenucggtffrrghtthgvrhhnpeeggfeuueffie dvgfefueeifeehheeuvdegheffledufefhlefhkefftdektdettdenucffohhmrghinhep rghnthhrrghnihhgvhdrrghmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomheprghnthhrrghnihhgvhesfhhrvggvsghsugdrrghm X-ME-Proxy: Feedback-ID: ibc494664:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 1 Feb 2024 11:07:11 -0500 (EST) From: Antranig Vartanian Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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.400.31\)) Subject: if_ixl: Admin Queue memory allocation issue hangs the server Message-Id: <7F49AE24-D3BC-4103-A522-75CB7BE477D0@freebsd.am> Date: Thu, 1 Feb 2024 20:07:00 +0400 Cc: "freebsd-net@freebsd.org" , "freebsd-hardware@freebsd.org" To: "freebsd-virtualization@freebsd.org" X-Mailer: Apple Mail (2.3774.400.31) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.95 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_SHORT(-0.95)[-0.946]; RWL_MAILSPIKE_EXCELLENT(-0.40)[64.147.123.20:from]; R_DKIM_ALLOW(-0.20)[freebsd.am:s=fm2,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.20:c]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.20:from]; DKIM_TRACE(0.00)[freebsd.am:+,messagingengine.com:+]; TO_DN_EQ_ADDR_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[freebsd.am]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-hardware@FreeBSD.org,freebsd-net@FreeBSD.org,freebsd-virtualization@FreeBSD.org]; ARC_NA(0.00)[]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+] X-Rspamd-Queue-Id: 4TQkLp69Jwz4tbw Greetings y=E2=80=99all, We have a massive server with two IXL NICs (Ethernet Controller X710 for = 10GBASE-T). One of them is on the host and the other is passed to a = guest running in a bhyve VM. Every once in a while, the system hangs. We cannot SSH, we cannot ping = nor we can login using console (IPMI remote screen). However, on the console, I see the following messages: "ixl0: ixl_process_adminq: Unable to allocate memory for Admin Queue = event!=E2=80=9D And it keeps repeating. The only way to get access to the host is to=E2=80=A6 reboot it. We don=E2=80=99t use SR-IOV (although when we did, the same thing = happened), we don=E2=80=99t use large MTUs (1500) nor we have a memory = issue (the system has 2TB of RAM, and right before hanging around 250G = is available). Any tip would be appreciated. P.S. we also tried the kmod from ports, still seeing the same issue. Kind regards, =E2=80=94 Antranig Vartanian https://antranigv.am/ PGP Key ID: 0x2D59F21C From nobody Thu Feb 1 19:19:43 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 4TQpcw4rHZz58Syt for ; Thu, 1 Feb 2024 19:19:44 +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 4TQpcw27pDz4KMC for ; Thu, 1 Feb 2024 19:19:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706815184; 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=rqtdw2uDDjLVXwHlOh/ENFX08XG937gN28KETZnBdEA=; b=QaWXRXmuW3/JW4LAmkgOUrYszyS44biRqMWQta+FfkY2Fe1XGrblvakg/XLJAsM0IwMW2B kbRGPYdZk1Nt3fE1e80h2IDaXrqyxC52P+1If8LFURl5e9LkJwDiSyKRnzmUFImOOC7OhN lFGXNvDMGn2ymdrN1Tba0WRSFHu0Wi9Et0HJcn15eDlB9uKXXCOJal/ygQnGT6tZkJ3rCf JdjiERSmuxqF+ojVjd6cl2TP+x7npdXGe7MzIhdd2888w27JP1QToVi4pwftLdt8ZtApMi sVeiXzgteZ3W6RACZXU7pKazy9tV+tY4JFpxLq6fXFOjvl6Vhflzf+BiExXnMA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706815184; a=rsa-sha256; cv=none; b=uLRUk9jNIMnnFoILCLoeocC01WuPP+EmlY7lI+O6xEahBn7thTrTQHQvKtXtWEe1vB2+QX vkENlY9f1J2IeokN38b+fmqiNQddLfmeloI52f+0mWkKby5EGj/RmktEjLohL4B4+Cmt+D CU+o/IkEfjdS1PkJcDrwpX5Hcap/irtZ0+shfiOZI9fvi+44mUZT5T+c28MfuW90qbbxCh KRF15q9USNPNEzv1UhzJgSOAXqnA++p0KXYC3cAPmvqHpFLM4/TQ3BqPka/rspmAQiNKrF qP3NfJta/oMYRiSM/IxlLXkhrP4xB2BNMipSGYO3v1YlQSVrGdxinK56HiXAMw== 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 4TQpcw162Rz1Dm2 for ; Thu, 1 Feb 2024 19:19: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 411JJitc092053 for ; Thu, 1 Feb 2024 19:19:44 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 411JJiHs092052 for net@FreeBSD.org; Thu, 1 Feb 2024 19:19:44 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 276760] vtnet driver incorrectly calculates checksums Date: Thu, 01 Feb 2024 19:19:43 +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: 13.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some 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=3D276760 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |net@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Thu Feb 1 23:28:26 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 4TQw7w01pkz58v0M for ; Thu, 1 Feb 2024 23:28:28 +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 4TQw7v645Jz4tLH for ; Thu, 1 Feb 2024 23:28:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706830107; 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=onhee0h8MSHi4B8o4s7laRoYiKYtXKu8LlsZoOpe8gM=; b=YwTqgloUt4TKliyMidRo+vwtuba1BgG2N4bJ6hvqXSUpwTOeTeDDDeOCxMGmkZzxq6uqDL RMKn8aZAEpsIozOay1H2Ibe5C6rPjp34zEyPjMFlcqQvphzPingfi2nSKdyihena8H6OUm LdygBNx691SN0WkzE8ExM7HIbVdIfjnq48vJyvLz8ek75blbqT2teBauKLxIf0eoIKk8o+ HWgYwIqaYr+lTz30jksnUFslT86hC7eGFgGUKASREbX23yiIS9kGIxJoD3bROMQ2lHtrSL Uf7sEf/ZhWWtu+C9HIt5R52yD7u/Yjrc12xCt8RJdvuSbW/iuJ3lfcTV7h9h4Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706830107; a=rsa-sha256; cv=none; b=xg43XPy8gKbw9/wNfRDgfT554U5h8YatfJzluNdpA/LlQXd3fEQvwkw3GsZQOHDYSo1Nyz YQQjZswO01XXQzlHhUxTh7Kych+3z/fBA+vSeLTh1jAytWSe0SxUhoquohuAhbRt4FErTG jc6HtacD2NE/xY9NqDO3A2cpjh09ChokrTctz55Urjlc8iTUmLqus6RhS+pxFueeeQM7Wm sLFP8T+JuShQ316xuEZ5sXVQFJj75hwZAemedzlD91HmeukNK1VMk1ePAPgyqLqBQaXaPC CR8pGFF91q+qZ7iXidXExhcHEusLmx8m0t+7rcbmiKVU+5jTEAX1X6nLpRMsSQ== 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 4TQw7v52nYz1LqT for ; Thu, 1 Feb 2024 23:28:27 +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 411NSRVO072611 for ; Thu, 1 Feb 2024 23:28:27 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 411NSRBM072610 for net@FreeBSD.org; Thu, 1 Feb 2024 23:28:27 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 276760] vtnet driver incorrectly calculates checksums Date: Thu, 01 Feb 2024 23:28:26 +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: 13.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: 000.fbsd@quip.cz 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=3D276760 Miroslav Lachman <000.fbsd@quip.cz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |000.fbsd@quip.cz --- Comment #3 from Miroslav Lachman <000.fbsd@quip.cz> --- I think I have related experience with csum vtnet bug. On one VM (in KVM) w= ith 2 vtnet NICs IPsec VPN the packets are not going thru until I disabled csum= on "LAN" NIC vtnet1: ifconfig_vtnet0=3D"inet AA.BB.CC.DD netmask 255.255.255.128" ifconfig_vtnet1=3D"inet WW.XX.YY.ZZ/24 -rxcsum -txcsum" This machine works like an IPsec gateway, vtnet0 is facing the internet, vt= net1 connects private network with clients connecting thru IPsec. Without -rxcsum -txcsum on vtnet1 the client machines cannot connect to anything in the outside world. First discovered with FreeBSD 12.3 (installed in the VM), later upgraded to 13.2. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Feb 2 01:09: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 4TQyNV6stFz594GT for ; Fri, 2 Feb 2024 01:09:30 +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 4TQyNV376sz44hq for ; Fri, 2 Feb 2024 01:09:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706836170; 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=54nPlkIK1iBx3v+ub2LH4sijQeUl0CLHXDG76dmeSdw=; b=rJAe9soDfwmqZZh5tIUjyOJQBxoIv6Ty3JOaRnne6JQ4q7e7FFSWZ6hZUWT3fyEQw7/K25 3ehtdet2xs8fS7kfwKkumvbhOOCmL5Rj59EFfFI21FsxqUwWg2gPb8XkhYv4UrZWpxb9AY RdSLUxqyj83xbK5Sj6JYD2GhucTWNIK/njZ4/j2L9dK/OhuxOQDnxonQ31+JDBwz67uRZe cTOwCtldqKt40PF+q43XIsH3YMkO/jHZuvCX47hjYFJHGXjT0BUrlI1g/gBHawCMBBZDS+ fQ5hWOPpAoVpT0x94BB9MU0YUTQ18VdsnB/bxTIUBA9EJ2bj3XRic87FIEYX3A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706836170; a=rsa-sha256; cv=none; b=hRW9lUwyQgfpCMwpYD2upb/ItH23pCYCYOcUjXGoZscmGWvW+S21EphkWnTMfSiFlVNCiL UIpmVcPC9zGdn/MJjvOGDCZ7439yMyMlY85fEBSicjyNMc2VLv7GRcvlKWb/gzzmKfNQw8 lvYmd9Ld9Nujw7zIT6tOws02mQRytuczNRBGLSQJi48TbbDz65VBsAjuvR1mJ1wZ8WFCeN Zu9iBVjvaMuWfiNg5YmGjviiky2+wwfrmlIp++I6Vzz5WnD58eyrKLF6A6KYA0qoQqx74j GU+yDjvBvG0dxK8aBGo+L0pYz8LHVtfgbtKAhUgxueOUArSKFDCFHpcbRaD1Wg== 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 4TQyNV24jDz1PFB for ; Fri, 2 Feb 2024 01:09:30 +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 41219UR3072316 for ; Fri, 2 Feb 2024 01:09:30 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 41219Um1072315 for net@FreeBSD.org; Fri, 2 Feb 2024 01:09: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 276772] wireguard: lock order reversal mld_mtx -> udpinp Date: Fri, 02 Feb 2024 01:09: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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me 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=3D276772 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |net@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Feb 2 05:49:44 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 4TR4bs1fCFz59V2l for ; Fri, 2 Feb 2024 05:49: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 4TR4br6kV1z4SKd for ; Fri, 2 Feb 2024 05:49:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706852984; 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=jzDtm6Jy4OTk4OXn/tBTWUlwK2LY52e3ZC/A416UT6o=; b=gHXDF3OtbJ6QOvp3vIW+QALkoMQjRn7j42Bh10B48xXhK/OHxbtbycgxoyw2XfuDp/5Ylr Gf/iuTCx49LKnecHc/D9xl/qw0MHhlQ3zdEU3P/H/u+M05DRIoVjO/zDF06amccYmVXLgS 2BAcvK346nMd5k2m7c+D07RZ7IPGNsP8DEg3RfF90LcO4WWnGsjYvK+3mUA6U7x7Ddm0HI fgXmacQ6Jh7Em4N/VTeB+sGRf85HlahCX4CPpfZD4IYAtkqxd1m43oea3HVpbNiO/UgUOF gUlsiC2NHrVWFPIGWbGoHmShPF2qt1J5Y2J3UDuTbSU5IVylxTWYqKoxw7iwnQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706852984; a=rsa-sha256; cv=none; b=tVntF8v+PzPUWwKoxE78JJvmneZxUsCiVe/B7huUmSldAd/aEN9sadCXlYUGJtvnUSXQrF p7BekkuKn9MK86a2CNFH4x72+2/2WX2/96nUn504F6BnmuPmIkZ4tV1GcCyft9w9r0yzPU E6MfHc69uJZCrf6NSYSIomL1ZDFiYAXEkNK6vWpZvVKLiTXkb0OK3lcn5WG7Bn+udUT+LL F3VLR3TlT2gE891/mmpXl9lhYqGEJPLcIjlvfNNb12qsbRhqv2rv3a3Y/jfKpm3N7Af++c ReO6L0Q7Yp+nKuUDBteFORUiqklk+95kk5s6r3unaNe+BwofH3rgtLpKaTlqiA== 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 4TR4br5jSYzJHb for ; Fri, 2 Feb 2024 05:49: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 4125niM9084666 for ; Fri, 2 Feb 2024 05:49:44 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4125niau084664 for net@FreeBSD.org; Fri, 2 Feb 2024 05:49:44 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 276774] IPv6 RS/RA handling Date: Fri, 02 Feb 2024 05:49:44 +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: 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=3D276774 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |net@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Feb 2 09:21:46 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 4TR9Jb2Mjqz58MNV; Fri, 2 Feb 2024 09:21:51 +0000 (UTC) (envelope-from rscheff@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4TR9Jb1sCTz4mGT; Fri, 2 Feb 2024 09:21:51 +0000 (UTC) (envelope-from rscheff@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706865711; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type:autocrypt:autocrypt; bh=mOvaPzYeToomQJOU+lrH7efIQCYNOF7zA2xnSoEvWaI=; b=VR8mq/XW0roKUy0nIca2JSO4Yohp1vvMeCoiulRNKOZhA3fZfj+sadun88VzvZFSVy+Vpj dd3XgtXuYc1WkuVOk8cTerIKdqJArj0JSVLZ/nUuX8ErlyBqM6dOrjoXd3HVLwGVK8AE0k pe0zRjn/9d0QoXjcFKuLR7tbYnUiH5W1F2jvGSAnrAWj4iEqdSWUcwR1+Z19ZGUk476ZvD 9/gu79DlGt+XBMjLDf8mSAP7y+xw6zwKHLnvr8uVWdjcvN01erAM62ZPR14sQGHldNJvtf NlWAqXINJo/kLr4rx/GuAFcDMQe51sXcyaVoRy4w/w6BSzmSEYX4G/PrVHQ6dQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706865711; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type:autocrypt:autocrypt; bh=mOvaPzYeToomQJOU+lrH7efIQCYNOF7zA2xnSoEvWaI=; b=mO7fFfkTcB8PldRS1vsIdumZGSwBY7jtLc7HLl5labbxBGlJ4Fa85liE9v1kkXFfvO51Rq DGW+fzhYf3fFEHEH32Fz1Ujp91NVaP8zxEhpMkwzObDkWnWXVW4CnR35HhssGhskcZf4v6 kjA6rzqn0/9MFM6alYnBmNuoT/Yr6TLlAYHiH+K2IJ89ReyK5XbO5s1dliJUpZ9IdRdveV NWynk4dRIESOe44f0Z6jLF5SNVo/QDSQqgKanyKo6Qeji6aiir4Q1J5chdEnPI4jZcWf2b /woOdLfp9TVwS3XETwxdkgH/fMtPsHbOFB96g9InNfyfxT2ffF4kWXixQ954dQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706865711; a=rsa-sha256; cv=none; b=UG0VuFqZNJnUt6I6C83ddZAjetfbtHyHwL7dw5jXSs491KPkaQeZ6IWTyVS7g2FFKKTLwp 9MaKpybrcquCDlR0VC0LbwasCzlgnKE8xYD83VscgAqK+r94lVOiZMYA097ZRPZX5eqpr3 9RunNUJR4B5oiP0Lmvuk87+dE12Gx+t2No5pHIo4jTJys13ylMl0hrYILopSZRN/pgbzrS nzfDbwfA3EFBw3cwFOQIvulBRVcIRSBcY0mm5LS8erU/jNy2mwFv6fS7IHwtB9Y+D6+Jv6 u9V4aV1gNLS7YGeVru6thQzKLfPyoR1VT0Avmmv84wQg5BvCldmM/9wi4fnUsA== Received: from [192.168.233.122] (unknown [185.236.167.136]) (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 did not present a certificate) (Authenticated sender: rscheff/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TR9JZ3h3RzXQM; Fri, 2 Feb 2024 09:21:50 +0000 (UTC) (envelope-from rscheff@freebsd.org) Message-ID: <2c31ac44-b34b-469c-a6de-fdd927ec2f9e@freebsd.org> Date: Fri, 2 Feb 2024 10:21:46 +0100 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 User-Agent: Mozilla Thunderbird To: "freebsd-net@FreeBSD.org" , FreeBSD Transport , rmacklem@freebsd.org, gallatin@FreeBSD.org, kp@FreeBSD.org From: "Scheffenegger, Richard" Subject: Increasing TCP TSO size support Autocrypt: addr=rscheff@freebsd.org; keydata= xjMEY/i74RYJKwYBBAHaRw8BAQdAwtnvjlFVnnzNXO9hjHtB6MPGSY19L/BHh/iziPF0FzrN K1JpY2hhcmQgU2NoZWZmZW5lZ2dlciA8cnNjaGVmZkBmcmVlYnNkLm9yZz7CmgQTFgoAQhYh BDZLt5msg0Ras820cRe+WJngsUObBQJj+LvhAhsDBQkJZgGABQsJCAcCAyICAQYVCgkICwIE FgIDAQIeBwIXgAAKCRAXvliZ4LFDm4ylAQCSw2/nvht8kExJ31M+3qpjOqdVypMp+/Ojvh5Z lsk96QEA5HCBkteJcrohwRA7llZvLH3m25hcJdzmDh39mc0cSgPOOARj+LvhEgorBgEEAZdV AQUBAQdA1Dim8ZWpXRS5i9hb3O4RNHub8XvqTTkYyiZ2lSkXDwYDAQgHwn4EGBYKACYWIQQ2 S7eZrINEWrPNtHEXvliZ4LFDmwUCY/i74QIbDAUJCWYBgAAKCRAXvliZ4LFDm2TGAQDcg+bA EPqOH+JCIND8wZ62MwnjFyXFv73qevXkUHHNSgEApUgpHW9f6UaIAQpc3R185xjz6tk8XXBx eYpxKgIAeQ8= Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------cFlXxpdNPSvFDnJ2Q7jJvaOb" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------cFlXxpdNPSvFDnJ2Q7jJvaOb Content-Type: multipart/mixed; boundary="------------imiNeDBqBOWYIblw01WKAtFz"; protected-headers="v1" From: "Scheffenegger, Richard" To: "freebsd-net@FreeBSD.org" , FreeBSD Transport , rmacklem@freebsd.org, gallatin@FreeBSD.org, kp@FreeBSD.org Message-ID: <2c31ac44-b34b-469c-a6de-fdd927ec2f9e@freebsd.org> Subject: Increasing TCP TSO size support --------------imiNeDBqBOWYIblw01WKAtFz Content-Type: multipart/mixed; boundary="------------f8bM96TDLFPthBSFcPuWJDK5" --------------f8bM96TDLFPthBSFcPuWJDK5 Content-Type: multipart/alternative; boundary="------------g30wiijxOrV2m8hMPa7cSCrN" --------------g30wiijxOrV2m8hMPa7cSCrN Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 DQpIaSwNCg0KV2UgaGF2ZSBydW4gYSB0ZXN0IGZvciBhIFJQQyB3b3JrbG9hZCB3aXRoIDFN QiBJTyBzaXplcywgYW5kIGNvbGxlY3RlZCANCnRoZSB0Y3BfZGVmYXVsdF9vdXRwdXQoKSBs ZW4oZ3RoKSBkdXJpbmcgdGhlIGZpcnN0IHBhc3MgaW4gdGhlIG91dHB1dCBsb29wLg0KDQpJ biBzdWNoIGEgc2NlbmFyaW8sIHdoZXJlIHRoZSBhcHBsaWNhdGlvbiBmcmVxdWVudGx5IGlu dHJvZHVjZXMgc21hbGwgDQpwYXVzZXMgKHNpbmNlIHRoZSBuZXh0IGxhcmdlIElPIGlzIG9u bHkgc2VudCBhZnRlciB0aGUgY29ycmVzcG9uZGluZyANCnJlcXVlc3QgZnJvbSB0aGUgY2xp ZW50IGhhcyBiZWVuIHJlY2VpdmVkIGFuZCBwcm9jZXNzZWQpIGJldHdlZW4gc2VuZGluZyAN CmFkZGl0aW9uYWwgZGF0YSwgdGhlIGN1cnJlbnQgVFNPIGxpbWl0IG9mIDY0a0IgVFNPIG1h eGltdW0gKDQ1KjE0NDggaW4gDQplZmZlY3QpIHJlcXVpcmVzIG11bHRpcGxlIHBhc3NlcyBp biB0aGUgb3V0cHV0IHJvdXRpbmUgdG8gc2VuZCBhbGwgdGhlIA0KYWxsb3dhYmxlIChjd25k IGxpbWl0ZWQpIGRhdGEuDQoNCkknbGwgdHJ5IHRvIGdldCBhIGRhdGEgY29sbGVjdGlvbiB3 aXRoIGJldHRlciBncmFudWxhcml5IGFib3ZlIDkwIDAwMCANCmJ5dGVzIC0gYnV0IGV2ZW4g aGVyZSB0aGUgYXZlcmFnZSBzdHJvbmdseSBpbmRpY2F0ZXMgdGhhdCBhIG1ham9yaXR5IG9m IA0KdHJhbnNtaXNzaW9uIG9wcG9ydHVuaXRpZXMgYXJlIGluIHRoZSA1MTIga0IgYXJlYSAt IHByb2JhYmx5IGFsc28gaGF2aW5nIA0KdG8gZG8gd2l0aCBMUk8gYW5kIEFDSyB0aGlubmlu ZyBlZmZlY3RzIGJ5IHRoZSBjbGllbnQuDQoNCldpdGggb3RoZXIgd29yZHMsIHRoZSB0Y3Ag b3V0cHV0IGhhcyB0byBydW4gYWJvdXQgOSB0aW1lcyB3aXRoIFRTTywgdG8gDQp0cmFuc21p dCBhbGwgZWxlZ2libGUgZGF0YSAtIGluY3JlYXNpbmcgdGhlIEZyZWVCU0Qgc3VwcG9ydGVk IG1heGltdW0gDQpUU08gc2l6ZSB0byB3aGF0IGN1cnJlbnQgaGFyZHdhcmUgY291bGQgaGFu ZGxlICgyNTZrQi4uMU1CKSB3b3VsZCByZWR1Y2UgDQp0aGUgQ1BVIGJ1cmRlbiBoZXJlLg0K DQoNCklzIGluY3JlYXNpbmcgdGhlIHNvZndhcmUgc3VwcG9ydGVkIFRTTyBzaXplIHRvIGFs bG93IGZvciB3aGF0IHRoZSBOSUNzIA0KY291bGQgbm93YWRheXMgZG8gc29tZXRoaW5nIGFu eW9uZSBhcGFydCBmcm9tIHVzIHdvdWxkIGJlIGludGVyZXN0ZWQgaW4gDQooaW4gcGFydGlj dWxhciwgdGhvc2Ugd2hvIHdvcmsgd2l0aCB0aGUgZHJpdmVycyk/DQoNCg0KQmVzdCByZWdh cmRzLA0KDQogwqAgUmljaGFyZA0KDQoNCg0KDQp0c28gc2l6ZSAodHJhbnNtaXNzaW9ucyA8 IDE0NDggd291bGQgbm90IGJlIGFjY291bnRlZCBoZXJlIGF0IGFsbCkNCg0KIMKgwqDCoCDC oMKgwqAgwqDCoMKgIMKgwqDCoCDCoMKgwqAgIyBjb3VudA0KDQo8MTAwMCAJMA0KPDIwMDAg CTIzDQo8MzAwMCAJMTExDQo8NDAwMCAJNDANCjw1MDAwIAkzMA0KPDcwMDAgCTE0DQo8ODAw MCAJMTM0DQo8OTAwMCAJNDQyDQo8MTAwMDAgCTkzOTYNCjwyMDAwMCAJNDYyMjcNCjwzMDAw MCAJMjU2NDYNCjw0MDAwMCAJMzMwNjANCjw2MDAwMCAJMjMxNjINCjw3MDAwMCAJMjQzNjgN Cjw4MDAwMCAJMTk3NzINCjw5MDAwMCAJNDAxMDENCiA+PTkwMDAwIAk3NTM4NDE2OQ0KQXZl cmFnZTogCTU3ODg0NC40NA0KDQo= --------------g30wiijxOrV2m8hMPa7cSCrN Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Hi,

We have run a test for a RPC workload with 1MB IO sizes, and collected the tcp_default_output() len(gth) during the first pass in the output loop.

In such a scenario, where the application frequently introduces small pauses (since the next large IO is only sent after the corresponding request from the client has been received and processed) between sending additional data, the current TSO limit of 64kB TSO maximum (45*1448 in effect) requires multiple passes in the output routine to send all the allowable (cwnd limited) data.

I'll try to get a data collection with better granulariy above 90 000 bytes - but even here the average strongly indicates that a majority of transmission opportunities are in the 512 kB area - probably also having to do with LRO and ACK thinning effects by the client.

With other words, the tcp output has to run about 9 times with TSO, to transmit all elegible data - increasing the FreeBSD supported maximum TSO size to what current hardware could handle (256kB..1MB) would reduce the CPU burden here.


Is increasing the sofware supported TSO size to allow for what the NICs could nowadays do something anyone apart from us would be interested in (in particular, those who work with the drivers)?

=


Best regards,

=C2=A0 Richard




tso size (transmissions < 1448 would not be accounted here at all)

=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 # count

<1000 0
<2000 23
<3000 111
<4000 40
<5000 30
<7000 14
<8000 134
<9000 442
<10000 9396
<20000 46227
<30000 25646
<40000 33060
<60000 23162
<70000 24368
<80000 19772
<90000 40101
>=3D90000 75384169
Average: 578844.44
--------------g30wiijxOrV2m8hMPa7cSCrN-- --------------f8bM96TDLFPthBSFcPuWJDK5 Content-Type: application/pgp-keys; name="OpenPGP_0x17BE5899E0B1439B.asc" Content-Disposition: attachment; filename="OpenPGP_0x17BE5899E0B1439B.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xjMEY/i74RYJKwYBBAHaRw8BAQdAwtnvjlFVnnzNXO9hjHtB6MPGSY19L/BHh/iz iPF0FzrNK1JpY2hhcmQgU2NoZWZmZW5lZ2dlciA8cnNjaGVmZkBmcmVlYnNkLm9y Zz7CmgQTFgoAQhYhBDZLt5msg0Ras820cRe+WJngsUObBQJj+LvhAhsDBQkJZgGA BQsJCAcCAyICAQYVCgkICwIEFgIDAQIeBwIXgAAKCRAXvliZ4LFDm4ylAQCSw2/n vht8kExJ31M+3qpjOqdVypMp+/Ojvh5Zlsk96QEA5HCBkteJcrohwRA7llZvLH3m 25hcJdzmDh39mc0cSgPOOARj+LvhEgorBgEEAZdVAQUBAQdA1Dim8ZWpXRS5i9hb 3O4RNHub8XvqTTkYyiZ2lSkXDwYDAQgHwn4EGBYKACYWIQQ2S7eZrINEWrPNtHEX vliZ4LFDmwUCY/i74QIbDAUJCWYBgAAKCRAXvliZ4LFDm2TGAQDcg+bAEPqOH+JC IND8wZ62MwnjFyXFv73qevXkUHHNSgEApUgpHW9f6UaIAQpc3R185xjz6tk8XXBx eYpxKgIAeQ8=3D =3DBwxS -----END PGP PUBLIC KEY BLOCK----- --------------f8bM96TDLFPthBSFcPuWJDK5-- --------------imiNeDBqBOWYIblw01WKAtFz-- --------------cFlXxpdNPSvFDnJ2Q7jJvaOb Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQQ2S7eZrINEWrPNtHEXvliZ4LFDmwUCZby0KgUDAAAAAAAKCRAXvliZ4LFDm73n AQC00+GZ7IDDzaPlORXmsNmMrrKgmFRT/rH6+MIpnbvA8AEA+130h9m/ksyrLjAOFWgXqG68ByH7 +gaZN4mhV5Q13Q0= =QnaZ -----END PGP SIGNATURE----- --------------cFlXxpdNPSvFDnJ2Q7jJvaOb-- From nobody Fri Feb 2 22:14:15 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 4TRVSF2spcz58Nrp; Fri, 2 Feb 2024 22:14:37 +0000 (UTC) (envelope-from gallatin@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 4TRVSF25c5z40RM; Fri, 2 Feb 2024 22:14:37 +0000 (UTC) (envelope-from gallatin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706912077; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=DjtbGOYAruVAO+vh5MF8LOAoRii6LS0uXXBjX+ehR1U=; b=QzX/5UC0ozDjLhqFyBtpK2PejmbCytLfc+jP15nI2VcItz4Rb8qldzOS95535nl56A7H37 R2hxR9DHdloUNnzXe0KpCR1CHJuCOgeLn9pFkIrwui4ZcSqmREQl1As1iZNvlRKzBV2A2m yAzpCefwfOo0eT9ousAVC/MrVAle7mHB56g3hnzOa1sovUdObE0R9zDlZ+CqjwNdTm2mTt +wOBOnDtTic4OloKFGKBjYZZV2rmjhrfwjdSh07no5sbnZHI5Ynb/LSFqBrXcEdoRnmkpb b2JB6UNf1pxNCyHRzH88u4TbfpnU6Z4D7vykclLsHCKQsFznl6AtFq9FjTEOXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706912077; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=DjtbGOYAruVAO+vh5MF8LOAoRii6LS0uXXBjX+ehR1U=; b=QfQkV0Y0i/C9rOBGyHM417YMKxTWJN78+rDZS2sCsUOkH5CyIdvrAyjXLWKkWx3gjszWdJ 90mUAdNtq0HzulpjjVwe526JqwKHqdUwH+vlo4z9LvDF3oFHym3kfT/smLEkrJhzlKNkx7 txGs1tgs21MV+efLxZOjjDtVIU5nmpoyMoGDjikD+1s6N6BOhwayRbt3NN7LUHv7+RNids jOMmXGOQOgA/ANYchsutY3ml386XN35fWCjqU3MuiRdWG04mnmdIrmkKCP4v3mfMyn+38Y Y4xvMPkEenxV1fsuXgh1wtQKAx1e4Ryd4JomkTEdbKoDL9FE1cXAzj0qxmWXuA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706912077; a=rsa-sha256; cv=none; b=ak3YWdgJ1XQ9UQtVnnDDBqsFKN3uDwEL6W/y0tNlmqz9l7BH5ip+fiHqP3cjzWGKdvegep 4/jgAOCOG1xPuI5GDqlKbnLqTCrdHBBtN4fQrSWHwuS+msHESDIXfT7spc29OQTmfqj/Zj eyembYZQD5SHsjzAy9RwkxqdYTFiEnmx1ODllRLP+3qgRlQqc3rS4bfMk+SasrF6rJZHjd WhJlHUDjwxJs/CoAPGyG9cxx3JBrCVfd+055U8yEmA4qdeh4qdp74b6JZNYShG9XdGtH20 lPJmiojrfMA4LG/Uo8f0LS+ufsYOB+SSQRRRrEtAaAZ3++IQT6IWMEuAbo1SyA== Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com [66.111.4.227]) (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) (Authenticated sender: gallatin) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TRVSF0qxMz11tq; Fri, 2 Feb 2024 22:14:37 +0000 (UTC) (envelope-from gallatin@freebsd.org) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailauth.nyi.internal (Postfix) with ESMTP id 2010D27C005B; Fri, 2 Feb 2024 17:14:36 -0500 (EST) Received: from imap53 ([10.202.2.103]) by compute5.internal (MEProxy); Fri, 02 Feb 2024 17:14:36 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrfedugedgudehjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfffhr vgifucfirghllhgrthhinhdfuceoghgrlhhlrghtihhnsehfrhgvvggsshgurdhorhhgqe enucggtffrrghtthgvrhhnpeehjeevleeigeefffdtgedtudegheetteeigfeileejuedv gefhvdekjedvhefhveenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehgrghllhgrthhinhdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihht hidqudeffeehledvvdduiedqvdelhedtgedukeegqdhgrghllhgrthhinheppehfrhgvvg gsshgurdhorhhgsehfrghsthhmrghilhdrtghomh X-ME-Proxy: Feedback-ID: i41414658:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id D7AF6364006B; Fri, 2 Feb 2024 17:14:35 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-144-ge5821d614e-fm-20240125.002-ge5821d61 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: <95e76a2c-44c8-4fbb-ab45-8bcffe80d4a3@app.fastmail.com> In-Reply-To: <2c31ac44-b34b-469c-a6de-fdd927ec2f9e@freebsd.org> References: <2c31ac44-b34b-469c-a6de-fdd927ec2f9e@freebsd.org> Date: Fri, 02 Feb 2024 17:14:15 -0500 From: "Drew Gallatin" To: "Richard Scheffenegger" , "freebsd-net@FreeBSD.org" , "FreeBSD Transport" , rmacklem@freebsd.org, kp@FreeBSD.org Subject: Re: Increasing TCP TSO size support Content-Type: multipart/alternative; boundary=16179d38f0f74410b648a6fe3220c987 --16179d38f0f74410b648a6fe3220c987 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable What is the link speed that you're working with? A long time ago, when I worked for a now-defunct 10GbE NIC vendor, I exp= erimented with the benefits of TSO as we varied the max TSO size. I ca= nnot recall the platform (it could have been OSX, Solaris, FreeBSD or Li= nux). At the time (~2006?) the CPU saving benefits of increasing the ma= x TSO size from 8k to 64k was fairly minimal. In fact, I seem to reca= ll that there was almost no benefit to TSO sizes larger than 16K. I was wondering if you see any difference in your benchmark if you cap m= ax TSO size to 8k, 16k,32k, and the default of 64k. Any change in CPU = use, or in your benchmark's performance would be interesting to hear abo= ut. Naively, I'd expect the benchmark performance to remain unchanged until = you'd reduced the TSO size so much as to make the host slower than the w= ire, thereby inserting gaps between TSOs. That would be reflected in th= e CPU use as well.. Drew On Fri, Feb 2, 2024, at 4:21 AM, Scheffenegger, Richard wrote: >=20 >=20 > Hi, >=20 > We have run a test for a RPC workload with 1MB IO sizes, and collected= the tcp_default_output() len(gth) during the first pass in the output l= oop. >=20 > In such a scenario, where the application frequently introduces small = pauses (since the next large IO is only sent after the corresponding req= uest from the client has been received and processed) between sending ad= ditional data, the current TSO limit of 64kB TSO maximum (45*1448 in eff= ect) requires multiple passes in the output routine to send all the allo= wable (cwnd limited) data. >=20 > I'll try to get a data collection with better granulariy above 90 000 = bytes - but even here the average strongly indicates that a majority of = transmission opportunities are in the 512 kB area - probably also having= to do with LRO and ACK thinning effects by the client. >=20 > With other words, the tcp output has to run about 9 times with TSO, to= transmit all elegible data - increasing the FreeBSD supported maximum T= SO size to what current hardware could handle (256kB..1MB) would reduce = the CPU burden here. >=20 >=20 >=20 > Is increasing the sofware supported TSO size to allow for what the NIC= s could nowadays do something anyone apart from us would be interested i= n (in particular, those who work with the drivers)? >=20 >=20 >=20 > Best regards, >=20 > Richard >=20 >=20 >=20 >=20 >=20 >=20 >=20 > tso size (transmissions < 1448 would not be accounted here at all) >=20 > # count >=20 >=20 >=20 > <1000 > 0 > <2000 > 23 > <3000 > 111 > <4000 > 40 > <5000 > 30 > <7000 > 14 > <8000 > 134 > <9000 > 442 > <10000 > 9396 > <20000 > 46227 > <30000 > 25646 > <40000 > 33060 > <60000 > 23162 > <70000 > 24368 > <80000 > 19772 > <90000 > 40101 > >=3D90000 > 75384169 > Average: > 578844.44 >=20 > *Attachments:* > =E2=80=A2 OpenPGP_0x17BE5899E0B1439B.asc > =E2=80=A2 OpenPGP_signature.asc --16179d38f0f74410b648a6fe3220c987 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
What is the lin= k speed that you're working with?

A long ti= me ago, when I worked for a now-defunct 10GbE NIC vendor, I experimented= with the benefits of  TSO as we varied the max TSO size.  I c= annot recall the platform (it could have been OSX, Solaris, FreeBSD or L= inux).  At the time (~2006?) the CPU saving benefits of increasing = the max TSO size from 8k to 64k was fairly minimal.    In= fact, I seem to recall that there was almost no benefit to TSO sizes la= rger than 16K.

I was wondering if you see a= ny difference in your benchmark if you cap max TSO size to 8k,  16k= ,32k, and the default of 64k.  Any change in CPU use, or in your be= nchmark's performance would be interesting to hear about.
=
Naively, I'd expect the benchmark performance to remain u= nchanged until you'd reduced the TSO size so much as to make the host sl= ower than the wire, thereby inserting gaps between TSOs.  That woul= d be reflected in the CPU use as well..

Dre= w

On Fri, Feb 2, 2024, at 4:21 AM, Scheffen= egger, Richard wrote:


Hi,

We have run a test for a RPC workload = with 1MB IO sizes, and collected the tcp_default_output() len(gth) during the first pass in the output loop.

In such a scenario, where the applic= ation frequently introduces small pauses (since the next large IO is only sent after the corresponding request from the client has been received and processed) between sending additional data, the current TSO limit of 64kB TSO maximum (45*1448 in effect) requires multiple passes in the output routine to send all the allowable (cwnd limited) data.

I'll try to get a data collection with better gran= ulariy above 90 000 bytes - but even here the average strongly indicates that a majority of transmission opportunities are in the 512 kB area - probably also having to do with LRO and ACK thinning effects by the client.

With other words, the tcp output has to run = about 9 times with TSO, to transmit all elegible data - increasing the FreeBSD supported maximum TSO size to what current hardware could handle (256kB..1MB) would reduce the CPU burden here.


<= p>Is increasing the sofware supported TSO size to allow for what the NICs could nowadays do something anyone apart from us would be interested in (in particular, those who work with the drivers)?


Best regards,

  Richard


=



tso size (transmissions < 1448 would not= be accounted here at all)

          &= nbsp;         # count


<1000
0
&l= t;2000
23
<300= 0
111
<400040
<5000
30
<7000
14
<8000
134
<= td style=3D"height:14.4pt;" height=3D"19"><9000
442
<10000
9396
<20000
46227
<30000
25646
<40000
= 33060
<60000
231= 62
<70000
2436= 8
<80000
19772=
<90000
40101<= br>>=3D90000
7538= 4169
Average:
578844.44

Attachments:
    =
  • OpenPGP_0x17BE5899E0B1439B.asc
  • OpenPGP_signature.asc
    =

--16179d38f0f74410b648a6fe3220c987-- From nobody Fri Feb 2 23:13:12 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 4TRWmB4QGPz58V4m; Fri, 2 Feb 2024 23:13:30 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 4TRWmB1nddz47Hk; Fri, 2 Feb 2024 23:13:30 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x434.google.com with SMTP id d2e1a72fcca58-6ddcfbc5a5fso2161627b3a.2; Fri, 02 Feb 2024 15:13:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706915609; x=1707520409; 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=DT8SAv3OA8HWqedgKXY2vWlbzyY8gnSoQtj351cRYIM=; b=fozHQcAdx71mQq8xAZGecXhQWKHOuXGbQDbLSnYBSAlFwb279+6q+3/oqjSp2jmH8I RGcGBih2B/bj6SHfcA64UeQlSW9iSBkEOglO28XGsLC39v96osAbMgQPHIS5NdSSafs/ bv5ysHaCBN0bWRLZui8emmt/BH1MaJu55kQC5yA5XcgTZAy+wwQ7cmE630+PSiGBETtP e+FXn+GEtpB+J99TjeBFOovcWkGKlpa8HQfDnDjrWkoUJalWt5eT3xOI7waXpSNGG0// 7k3RQ5f+z/ZcKT18QDDDsQlXABHJbFXdVWSiN3e6GDI8yT4965k76XkfZqSSdX5O/hAy B5Fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706915609; x=1707520409; 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=DT8SAv3OA8HWqedgKXY2vWlbzyY8gnSoQtj351cRYIM=; b=I/+ZxDis5v8uzX1BJYO9iYivsXUp75/oVhS4P3MwdhLvxeXwQRWAtpLBcdBXt4+hrO fXaccYb0yQYRF8IzeHIs2zZFO0JHthKrTzwZPM1GmELE+AYDnZi2qCI/GhovWPZdq8Jq yGdzz7q+L5wHNu3k8U4JRV8Qo1jW7rLBvcUTADiVA8469Cpz5F+dOMyxL8NsmDwETHxR s/+TjIGJozQB8JYzscchaK3vMM40bLrULnZuwR7JwbhrY1g9wxwHZQbVtzVZrSyAgt0L VS9noBt62HmPEm6paOzYrs6rhhOh0mfB0lKZo48nH3XEi2C+FI8Pkvsdli0yj6dXDGXq e0/Q== X-Gm-Message-State: AOJu0YyBpZl7YJSLhyhJ6+t5z2FXtGsRtRP79GZFI5YaIz9FAbgojRNP ynrQUCL0RyI9c+bm1pAd8aRm6+NF+Ld5I35MHn0LljKDSPwdfPmpRkZflDgH0eflx2VSi9e32Cv ldac2wtipEwm7vw4iHObW/P3CbX5+O6PoGg== X-Google-Smtp-Source: AGHT+IGefsytDfxEzs1sh45HxZ75tQa/nSAXqdwTkI/Q+8i0uM47YdV3moy68htKVDBNtqDp0f2i6WZ2ZLSgZ946JvU= X-Received: by 2002:a05:6a00:2295:b0:6db:ca49:9ce3 with SMTP id f21-20020a056a00229500b006dbca499ce3mr8775204pfe.6.1706915608868; Fri, 02 Feb 2024 15:13:28 -0800 (PST) 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: <2c31ac44-b34b-469c-a6de-fdd927ec2f9e@freebsd.org> In-Reply-To: <2c31ac44-b34b-469c-a6de-fdd927ec2f9e@freebsd.org> From: Rick Macklem Date: Fri, 2 Feb 2024 15:13:12 -0800 Message-ID: Subject: Re: Increasing TCP TSO size support To: "Scheffenegger, Richard" Cc: "freebsd-net@FreeBSD.org" , FreeBSD Transport , rmacklem@freebsd.org, gallatin@freebsd.org, kp@freebsd.org Content-Type: multipart/alternative; boundary="000000000000873cc506106e420e" X-Rspamd-Queue-Id: 4TRWmB1nddz47Hk 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)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] --000000000000873cc506106e420e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Feb 2, 2024 at 1:21=E2=80=AFAM Scheffenegger, Richard wrote: > > Hi, > > We have run a test for a RPC workload with 1MB IO sizes, and collected th= e > tcp_default_output() len(gth) during the first pass in the output loop. > > In such a scenario, where the application frequently introduces small > pauses (since the next large IO is only sent after the corresponding > request from the client has been received and processed) between sending > additional data, the current TSO limit of 64kB TSO maximum (45*1448 in > effect) requires multiple passes in the output routine to send all the > allowable (cwnd limited) data. > > I'll try to get a data collection with better granulariy above 90 000 > bytes - but even here the average strongly indicates that a majority of > transmission opportunities are in the 512 kB area - probably also having = to > do with LRO and ACK thinning effects by the client. > > With other words, the tcp output has to run about 9 times with TSO, to > transmit all elegible data - increasing the FreeBSD supported maximum TSO > size to what current hardware could handle (256kB..1MB) would reduce the > CPU burden here. > > > Is increasing the sofware supported TSO size to allow for what the NICs > could nowadays do something anyone apart from us would be interested in (= in > particular, those who work with the drivers)? > Reposted after joining freebsd-net@... A factor here is the if_hw_tsomaxsegcount limit. For example, a 1Mbyte NFS write request or read reply will result in a 514 element mbuf chain. Each of these (mostly 2K mbuf clusters) are non-contiguous data segments. (I suspect most NICs do not handle this many segments well, if at all.) The NFS code does know how to use M_EXTPG mbufs (for NFS over TLS, for the ktls), but I do not know what it would take to make these work for non-KTLS TSO? I do not know how the TSO loop in tcp_output handles M_EXTPG mbufs. Does it assume each M_EXTPG mbuf is one contiguous data segment? I do see that ip_output() will call mb_unmapped_to_ext() when the NIC does not have IFCAP_MEXTPG set. (If IFCAP_MEXTPG is set, do the pages need to be contiguous so that it can become a single contiguous data segment for TSO or ???) If TSO and the code beneath it (NIC and maybe mb_unmapped_to_ext() being called) were to all work ok for M_EXTPG mbufs, it would be easy to enable that for NFS (non-TLS case). I do not want to hijack this thread, but do others know how TSO interacts with M_EXTPG mbufs? rick > Best regards, > > Richard > > > > > tso size (transmissions < 1448 would not be accounted here at all) > > # count > > <1000 0 > <2000 23 > <3000 111 > <4000 40 > <5000 30 > <7000 14 > <8000 134 > <9000 442 > <10000 9396 > <20000 46227 > <30000 25646 > <40000 33060 > <60000 23162 > <70000 24368 > <80000 19772 > <90000 40101 > >=3D90000 75384169 > Average: 578844.44 > > CAUTION: This email originated from outside of the University of Guelph. > Do not click links or open attachments unless you recognize the sender an= d > know the content is safe. If in doubt, forward suspicious emails to > IThelp@uoguelph.ca. > > --000000000000873cc506106e420e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Feb 2, 2024 at 1:21= =E2=80=AFAM Scheffenegger, Richard <rscheff@freebsd.org> wrote:
=20 =20 =20


Hi,

We have run a test for a RPC workload with 1MB IO sizes, and collected the tcp_default_output() len(gth) during the first pass in the output loop.

In such a scenario, where the application frequently introduces small pauses (since the next large IO is only sent after the corresponding request from the client has been received and processed) between sending additional data, the current TSO limit of 64kB TSO maximum (45*1448 in effect) requires multiple passes in the output routine to send all the allowable (cwnd limited) data.

I'll try to get a data collection with better granulariy above 9= 0 000 bytes - but even here the average strongly indicates that a majority of transmission opportunities are in the 512 kB area - probably also having to do with LRO and ACK thinning effects by the client.

With other words, the tcp output has to run about 9 times with TSO, to transmit all elegible data - increasing the FreeBSD supported maximum TSO size to what current hardware could handle (256kB..1MB) would reduce the CPU burden here.


Is increasing the sofware supported TSO size to allow for what the NICs could nowadays do something anyone apart from us would be interested in (in particular, those who work with the drivers)?

Reposted after joining freebsd-net@...
=C2=A0
=C2=A0A factor here is the if_= hw_tsomaxsegcount limit. For example, a 1Mbyte NFS write request
or read repl= y will result in a 514 element mbuf chain. Each of these (mostly 2K mbuf cl= usters)
a= re non-contiguous data segments. (I suspect most NICs do not handle this ma= ny segments well,
if at all.)

The NFS code does know how to use M_EXTPG mbufs (for NFS over TLS, = for the ktls), but I do not
know what it would take to make these work for non-KTLS = TSO?
I do= not know how the TSO loop in tcp_output handles M_EXTPG mbufs.
Does it assume each = M_EXTPG mbuf is one contiguous data segment?
I do see that ip_output() will call mb_= unmapped_to_ext() when the NIC does not have IFCAP_MEXTPG set.
(If IFCAP_MEXTPG is s= et, do the pages need to be contiguous so that it can become
a single contiguous dat= a segment for TSO or ???)

If TSO and the code beneath it (NIC and maybe mb_unmapped_to_e= xt() being called) were to
all work ok for M_EXTPG mbufs, it would be easy to enable= that for NFS (non-TLS case).

I do not want to hijack this thread, but do others know ho= w TSO interacts with M_EXTPG
mbufs?

rick


Best regards,

=C2=A0 Richard




tso size (transmissions < 1448 would not be accounted here at all)

=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 # count

<1000 0
<2000 23
<3000 111
<4000 40
<5000 30
<7000 14
<8000 134
<9000 442
<10000 9396
<20000 46227
<30000 25646
<40000 33060
<60000 23162
<70000 24368
<80000 19772
<90000 40101
>=3D90000 75384169
Average: 578844.44

CAUTION: This email originated from o= utside of the University of Guelph. Do not click links or open attachments = unless you recognize the sender and know the content is safe. If in doubt, = forward suspicious emails to IThelp@uoguelph.ca.

--000000000000873cc506106e420e-- From nobody Sat Feb 3 00:47:40 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 4TRYsF0Zlxz58f7J; Sat, 3 Feb 2024 00:48:01 +0000 (UTC) (envelope-from gallatin@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4TRYsF00qYz4KQ6; Sat, 3 Feb 2024 00:48:01 +0000 (UTC) (envelope-from gallatin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706921281; 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=RJhZ2pmFa8Mh9nqZ8Q6UxZA2Ks25X7DGKKB3ByQW1tU=; b=tLBNgZUZSmIZEcnVsMrdD7YyUvXmym8JRAE9Wq9DhTeNq52i+RBIdvjlJgX10oeixCtjyC UA6vw+i+8oAHIgnepD4q34xU3x97Gr+9M2/nOjXtZLyN1yu49gcKCzApdPGL4xgyYrmSrS 0iP9Ljwgr7vRcPmdcOTOZOVHHLJhOJhO/fsXyq+NQP+A+ka2P/oqBAO6LZfJ2ZXYJupiH/ ECOiaaOsb0qqbzP87lfxj98Y5jESU2CcT0AFAAo/4dVOUzACIkejW8UjjGp619kJn4/ib1 NjOlLxXoaYz5uTWdcmg3sEdOrq0g+mrat4uwJ/X/FFwzE9M9Q3//mnSKCaxDqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706921281; 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=RJhZ2pmFa8Mh9nqZ8Q6UxZA2Ks25X7DGKKB3ByQW1tU=; b=MiPYRNOKuSgyPWhacpL48sAhBf1uopCHaUvUjIaloa7D9ffju2GwMHL/1idwFy4Y8eykQF RWLsOs9rj94HcSqdx0etEHYiSipeWorOLIJheH/yT0S6Fkq8k1rhCVIvN2mXN7oR4clAe1 kh0+tQfA7UD9KfPBVQuhny1WdX7oR5wJ5mnVcv3nRd1OW/P+8W0hO4c48+j+lxK0J55lfw x0R5IyigII7HY/wUJyqnWrvsmbV7oJm5EiRwqD7ykhWUEjARHNQMM23PPPhg5JcXvTskVf 2krL8wZ8tQ6PJ69VV7M2Wj4YuELqgv+a2AalPH0Vqyf3bO557pAFCTS/V06Qig== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706921281; a=rsa-sha256; cv=none; b=cepMKxf3i6raG/McEVMYvW7FMn6AE5aVW6ogWtKXjQ1aTPKZKA11aG9/PuzITyOvNNYng3 gYyVFDBGUNN2QKKravf/vepUclSlRiY54n38tba423Ld7knnZ1upZ+g435sSx8TKT4SkRP QlkBxWR9hYS/MeZwP00jS4TvPO8ge7GTCM01sMIYDHOW9URxx3N14qfXA0tR6VC5lfoKeL vJeOAnulYm25jGj4ZgGcmW4zWPTdYBunJmhpxP1wbrl0vjWSn9hRLWxqBdC9F5cjrkIS+b wNX1mlctNUadLHVt+eCvY5s/QUCZlZtiwG64Uo+70QHM55cZVO1LJPCG7QV5nA== Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com [66.111.4.228]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: gallatin) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TRYsD5nLyz14jZ; Sat, 3 Feb 2024 00:48:00 +0000 (UTC) (envelope-from gallatin@freebsd.org) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailauth.nyi.internal (Postfix) with ESMTP id A5FDA27C005B; Fri, 2 Feb 2024 19:48:00 -0500 (EST) Received: from imap53 ([10.202.2.103]) by compute5.internal (MEProxy); Fri, 02 Feb 2024 19:48:00 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrfeduhedgvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsegrtderreerredtnecuhfhrohhmpedfffhr vgifucfirghllhgrthhinhdfuceoghgrlhhlrghtihhnsehfrhgvvggsshgurdhorhhgqe enucggtffrrghtthgvrhhnpeeggfeugeevuedtuedvleefffduteegtdffudeihefhgfeg feekffeiueevkeeuudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehgrghllhgrthhinhdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihht hidqudeffeehledvvdduiedqvdelhedtgedukeegqdhgrghllhgrthhinheppehfrhgvvg gsshgurdhorhhgsehfrghsthhmrghilhdrtghomh X-ME-Proxy: Feedback-ID: i41414658:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 68C46364006B; Fri, 2 Feb 2024 19:48:00 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-144-ge5821d614e-fm-20240125.002-ge5821d61 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: <2c31ac44-b34b-469c-a6de-fdd927ec2f9e@freebsd.org> Date: Fri, 02 Feb 2024 19:47:40 -0500 From: "Drew Gallatin" To: "Rick Macklem" , "Richard Scheffenegger" Cc: "freebsd-net@FreeBSD.org" , "FreeBSD Transport" , rmacklem@freebsd.org, kp@freebsd.org Subject: Re: Increasing TCP TSO size support Content-Type: multipart/alternative; boundary=d72aaec284da4bab8e1160d4085e3fc4 --d72aaec284da4bab8e1160d4085e3fc4 Content-Type: text/plain On Fri, Feb 2, 2024, at 6:13 PM, Rick Macklem wrote: > A factor here is the if_hw_tsomaxsegcount limit. For example, a 1Mbyte NFS write request > or read reply will result in a 514 element mbuf chain. Each of these (mostly 2K mbuf clusters) > are non-contiguous data segments. (I suspect most NICs do not handle this many segments well, > if at all.) Excellent point > > The NFS code does know how to use M_EXTPG mbufs (for NFS over TLS, for the ktls), but I do not > know what it would take to make these work for non-KTLS TSO? Sendfile already uses M_EXTPG mbufs... When I was initially doing M_EXTPG stuff for kTLS, I added support for using M_EXTPG mbufs in sendfile regardless of whether or not kTLS was in use. That reduced CPU use marginally on 64-bit platforms (due to reducing socket buffer lengths, and hence reducing pointer chasing), and quite a bit more on 32-bit platforms (due to also not needing to map memory into the kernel map, and by reducing pointer chasing even more, as more pages fit into an M_EXTPG mbuf when a paddr_t is 32-bits. > I do not know how the TSO loop in tcp_output handles M_EXTPG mbufs. > Does it assume each M_EXTPG mbuf is one contiguous data segment? No, its fully aware of how to handle M_EXTPG mbufs. Look at tcp_m_copy(). We added code in the segment counting part of that function to count the hdr/trailer parts of an M_EXTPG mbuf, and to deal with the start/end page being misaligned. > I do see that ip_output() will call mb_unmapped_to_ext() when the NIC does not have IFCAP_MEXTPG set. > (If IFCAP_MEXTPG is set, do the pages need to be contiguous so that it can become > a single contiguous data segment for TSO or ???) No, it just means that a NIC driver has been verified to call not mtod() an M_EXTPGS mbuf and deref the resulting data pointer. (which would make it go "boom"). But the page size is only 4K on most platforms. So while an M_EXTPGS mbuf can hold 5 pages (..from memory, too lazy to do the math right now) and reduces socket buffer mbuf chain lengths by a factor of 10 or so (2k vs 20k per mbuf), the S/G list that a NIC will need to consume would likely decrease only by a factor of 2. And even then only if the busdma code to map mbufs for DMA is not coalescing adjacent mbufs. I know busdma does some coalescing, but I can't recall if it coalesces physcally adjacent mbufs. > If TSO and the code beneath it (NIC and maybe mb_unmapped_to_ext() being called) were to > all work ok for M_EXTPG mbufs, it would be easy to enable that for NFS (non-TLS case). It does. You should enable it for at least TCP. Drew --d72aaec284da4bab8e1160d4085e3fc4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

=
On Fri, Feb 2, 2024, at 6:13 PM, Rick Macklem wrote:
<= /div>
 A factor here is the if_hw_tsomaxse= gcount limit. For example, a 1Mbyte NFS write request
or read r= eply will result in a 514 element mbuf chain. Each of these (mostly 2K m= buf clusters)
are non-contiguous data segments. (I suspect most NICs d= o not handle this many segments well,
if at all.)

Excellent point
=

The NFS code does know how to= use M_EXTPG mbufs (for NFS over TLS, for the ktls), but I do not
know= what it would take to make these work for non-KTLS TSO?
=


Sendfile alr= eady uses M_EXTPG mbufs... When I was initially doing M_EXTPG stuff for = kTLS, I added support for using M_EXTPG mbufs in sendfile regardless of = whether or not kTLS was in use.  That reduced CPU use marginally on= 64-bit platforms (due to reducing socket buffer lengths, and hence redu= cing pointer chasing), and quite a bit more on 32-bit platforms (due to = also not needing to map memory into the kernel map, and by reducing poin= ter chasing even more, as more pages fit into an M_EXTPG mbuf when a pad= dr_t is 32-bits.


I do not know how the TSO loop in tcp_output handles M_E= XTPG mbufs.
Does it assume each M_EXTPG mbuf is one contiguous data se= gment?

No, i= ts fully aware of how to handle M_EXTPG mbufs.  Look at tcp_m_copy(= ).  We added code in the segment counting part of that function to = count the hdr/trailer parts of an M_EXTPG mbuf, and to deal with the sta= rt/end page being misaligned.

I do see that ip_output() will call mb_unmapped_to_ext() wh= en the NIC does not have IFCAP_MEXTPG set.
(If IFCAP_MEXTPG is set, do= the pages need to be contiguous so that it can become
a single contig= uous data segment for TSO or ???)

No, it just means that a NIC driver has been verif= ied to call not mtod() an M_EXTPGS mbuf and deref the resulting data poi= nter. (which would make it go "boom").

But = the page size is only 4K on most platforms.  So while an M_EXTPGS m= buf can hold 5 pages (..from memory, too lazy to do the math right now) = and reduces socket buffer mbuf chain lengths by a factor of 10 or so (2k= vs 20k per mbuf), the S/G list that a NIC will need to consume would li= kely decrease only by a factor of 2.  And even then only if the bus= dma code to map mbufs for DMA is not coalescing adjacent mbufs.  I = know busdma does some coalescing, but I can't recall if it coalesces phy= scally adjacent mbufs. 

If TSO and the code beneath it (NIC and maybe mb_unmapped_t= o_ext() being called) were to
all work ok for M_EXTPG mbufs, it would = be easy to enable that for NFS (non-TLS case).


It does.  You sho= uld enable it for at least TCP.

Drew
--d72aaec284da4bab8e1160d4085e3fc4-- From nobody Sat Feb 3 02:05:08 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 4TRbZZ31jGz58mXY; Sat, 3 Feb 2024 02:05:26 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 4TRbZZ16v3z4c8m; Sat, 3 Feb 2024 02:05:26 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x42b.google.com with SMTP id d2e1a72fcca58-6ddb807e23bso1809618b3a.0; Fri, 02 Feb 2024 18:05:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706925925; x=1707530725; 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=29dENUEreQygO9lXAShO8R1E0pc0lox2QNPAePhG7vI=; b=QC0apdtlKx/88dTL6Wmqsp33SFvHQ219YTZqdD6fay6/D/Q09Sgr1pz1Dl65xwkc/D boy5ARCpQI9mFhvvw/mv5QjUEPb2u7y4vy5T07LNOqL5hz9eQ3g6rcctLz0+iCziYujA ThAo0njct4oDxBnn3VZbUczQ63vFI+paukFAdCwpGDVTUXAefCvtOzIFVb61twTtEIjw nkQrVCsZZKhJpPNmhQhybCPSIA8UV7imLciPFrDAROK+lisb6EoK7u+h8m23XeuqqvQk 6gFPS9Vl7EIxPb6ODD6YcIPOPrVsi1NZ4iznVkROFPapIHsXGI12tj5fUIuFrHim/xF6 JPpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706925925; x=1707530725; 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=29dENUEreQygO9lXAShO8R1E0pc0lox2QNPAePhG7vI=; b=hXjenw9/ybdSnZPM3qAf35prNDa3cJvubZYTeKET5GboWSkfLNCg7imIBIlpdRLYVa M8G27USK5wy9E27a4qRr5cs1mK9bm7XWeXfZ75rRMVOToJJwbV+KyIIKaRXBG3h4OoJ7 EolossLTE7fobQv+CUKBEln5In148nDapE4WBTQbOrEaacoovDP4Hkj+K6tDxyHQRNtT /OGatHEZtlMEQDtiCSnsMd6TgTNGdt7MDM3b23JDUDVa1b/toNxt0r7E3volr6Mqv0q8 NPyajbTYokRSw50dGscCWQwRSkFFVQAJp2w+1VOD2u3m9PXZoorirfK39sv9sCquigl0 5gKA== X-Gm-Message-State: AOJu0YyP+9P2gjR8l/4uMdLXXhgJl5PEOx4nxp261yrIC1ASP2dp/yoi 7ivgBjpKKKiyEbvFmf8aPSrfqIrnMAgek2CAuJE7N8tJNjjHyAoISWC9gz5VCuro6qygYDmUZE3 ivdVXtm8jmNY7M2094U/RnXt3S2s0tuY= X-Google-Smtp-Source: AGHT+IGUVkguJTvjMJNlQtfURLSi0+dKeVy0PlQSgJPitZuinHoxbAojv8G7F7jj+KNMPNG8CzXSj9G5msp3bP6nmPI= X-Received: by 2002:a05:6a00:90a2:b0:6e0:23e7:cec6 with SMTP id jo34-20020a056a0090a200b006e023e7cec6mr2720634pfb.26.1706925924770; Fri, 02 Feb 2024 18:05:24 -0800 (PST) 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: <2c31ac44-b34b-469c-a6de-fdd927ec2f9e@freebsd.org> In-Reply-To: From: Rick Macklem Date: Fri, 2 Feb 2024 18:05:08 -0800 Message-ID: Subject: Re: Increasing TCP TSO size support To: Drew Gallatin Cc: Richard Scheffenegger , "freebsd-net@FreeBSD.org" , FreeBSD Transport , rmacklem@freebsd.org, kp@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TRbZZ16v3z4c8m 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)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] On Fri, Feb 2, 2024 at 4:48=E2=80=AFPM Drew Gallatin = wrote: > > > > On Fri, Feb 2, 2024, at 6:13 PM, Rick Macklem wrote: > > A factor here is the if_hw_tsomaxsegcount limit. For example, a 1Mbyte N= FS write request > or read reply will result in a 514 element mbuf chain. Each of these (mos= tly 2K mbuf clusters) > are non-contiguous data segments. (I suspect most NICs do not handle this= many segments well, > if at all.) > > > Excellent point > > > The NFS code does know how to use M_EXTPG mbufs (for NFS over TLS, for th= e ktls), but I do not > know what it would take to make these work for non-KTLS TSO? > > > > Sendfile already uses M_EXTPG mbufs... When I was initially doing M_EXTPG= stuff for kTLS, I added support for using M_EXTPG mbufs in sendfile regard= less of whether or not kTLS was in use. That reduced CPU use marginally on= 64-bit platforms (due to reducing socket buffer lengths, and hence reducin= g pointer chasing), and quite a bit more on 32-bit platforms (due to also n= ot needing to map memory into the kernel map, and by reducing pointer chasi= ng even more, as more pages fit into an M_EXTPG mbuf when a paddr_t is 32-b= its. > > > I do not know how the TSO loop in tcp_output handles M_EXTPG mbufs. > Does it assume each M_EXTPG mbuf is one contiguous data segment? > > > No, its fully aware of how to handle M_EXTPG mbufs. Look at tcp_m_copy()= . We added code in the segment counting part of that function to count the= hdr/trailer parts of an M_EXTPG mbuf, and to deal with the start/end page = being misaligned. > > I do see that ip_output() will call mb_unmapped_to_ext() when the NIC doe= s not have IFCAP_MEXTPG set. > (If IFCAP_MEXTPG is set, do the pages need to be contiguous so that it ca= n become > a single contiguous data segment for TSO or ???) > > > No, it just means that a NIC driver has been verified to call not mtod() = an M_EXTPGS mbuf and deref the resulting data pointer. (which would make it= go "boom"). > > But the page size is only 4K on most platforms. So while an M_EXTPGS mbu= f can hold 5 pages (..from memory, too lazy to do the math right now) and r= educes socket buffer mbuf chain lengths by a factor of 10 or so (2k vs 20k = per mbuf), the S/G list that a NIC will need to consume would likely decrea= se only by a factor of 2. And even then only if the busdma code to map mbu= fs for DMA is not coalescing adjacent mbufs. I know busdma does some coale= scing, but I can't recall if it coalesces physcally adjacent mbufs. I'm guessing the factor of 2 comes from the fact that each page is a contiguous segment? The NFS code could easily use 5 contiguous pages, so maybe it would be worthwhile to try and make some NIC drivers capable of handling contiguous pages as one segment for TSO output? (It means that tcp_outpout() would need to know this case was possible, Maybe a new if_hw_tsoXX that covers the max number of segments if pages are contig?) However, given your previous post, it might not matter much, since the larger TSO segment might not make much difference? > > If TSO and the code beneath it (NIC and maybe mb_unmapped_to_ext() being = called) were to > all work ok for M_EXTPG mbufs, it would be easy to enable that for NFS (n= on-TLS case). > > > > It does. You should enable it for at least TCP. Good work!! I will try it someday relatively soon. Even if it only reduces the use of mbuf clusters, that sounds like it would be worthwhile. rick > > Drew From nobody Sat Feb 3 02:19:41 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 4TRbvQ2BgNz58nyd; Sat, 3 Feb 2024 02:20:02 +0000 (UTC) (envelope-from gallatin@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4TRbvQ1WWTz4d94; Sat, 3 Feb 2024 02:20:02 +0000 (UTC) (envelope-from gallatin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706926802; 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=etFOi/HDfAtXaVCgcNdajbpYwcPoJvXj7bW98kLT/po=; b=NfQUwXtYrjwXJuRycqG9AMtFvc9AD3FqMzTyKIdWPYbuGRjXhgzEG9OoxM3DpVdlzPn6Zg ISsCksi54gNvCe5cOgFV2GfICF06RpLWXklRdEKnJV3bnBWq8lz336O1wlrD8f802TLaKF +Dpj8zhRmprcIulqs9uHgVwA8OCdz2hSI+rYGiYs8ryEzVShZqbZdZvvyvYvy9FQHX2M/9 5aOgNvftHBp25rTDV8gc7kZqayj3TGQY0ihNuiWW6duF862ZVbEb2NNRQKhHgnG+NBOTnz SHcrcwm69tQtcRBxZetUV1Xh4WSYaZgjCvPheF0L8ZTJ6kPi3Wrhv3VmtteoAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706926802; 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=etFOi/HDfAtXaVCgcNdajbpYwcPoJvXj7bW98kLT/po=; b=GJn5vXcU8PXqN6BCV6aeNpocNHK9GZgCMm0yk+By33va4SLvcNwTQL+GTYRGqqutLny29W qWyjwfHchMCEskTGpBdeFcaptIxJnvIwLevhIs2ID2AZ6gCO0cgkm45PaBXaVuQXWlo/81 ctwxqdWsqGFJgQN5kncf7r+flzvepv/DnkpjCn7O/Tbto8BVA6lRUmeSgLdETjf+fKQ5CZ O5uFCbbWoUuXKyqcvLpVxujD05d1TS7TosS3u1hRcTUuZE9/gPbd8TClQT1PA+V8X9QLKF Vwd/NWu1WT3uGI9jkyX0YV3ts+hvQd9UJhU9JT7MBZdC/MfOvG5DmTrV0jV2Zg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706926802; a=rsa-sha256; cv=none; b=iY0bGE0hlhgJUq9hmfDKaq0Z8kYL3t/R454OIOpDr39dp/AkYneAnpz4QhD6wMmhU+OugS vkn2fnQMXfyJM9/i8id/BUFvClJfmtIaqbgBjtHXDMqzbLzA5HTSwlLD07jkzSrFqoh0ME 8rvZ7avWslvbiyPhpjTxaQWAe35jm/o0+bpq4wPpwZwISQFiActxOAiT0oK52AoH1W4DRd SNcXiV0i3f4dZuyj+jVCtjsu6beZjrGTKPsJgO4V/eIJsG/5JS2pbrWZtfCeJiEy6uBsDL 3j2KdsOheYYIoDczKTVWuLtIsK8RQiZaj7x9MU3JYfwKB0sgfWqELAhIz4heeA== Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com [66.111.4.227]) (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) (Authenticated sender: gallatin) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TRbvQ0Dp2z15Vv; Sat, 3 Feb 2024 02:20:02 +0000 (UTC) (envelope-from gallatin@freebsd.org) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailauth.nyi.internal (Postfix) with ESMTP id E525E27C0061; Fri, 2 Feb 2024 21:20:01 -0500 (EST) Received: from imap53 ([10.202.2.103]) by compute5.internal (MEProxy); Fri, 02 Feb 2024 21:20:01 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrfeduhedggeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsegrtderreerredtnecuhfhrohhmpedfffhr vgifucfirghllhgrthhinhdfuceoghgrlhhlrghtihhnsehfrhgvvggsshgurdhorhhgqe enucggtffrrghtthgvrhhnpeeggfeugeevuedtuedvleefffduteegtdffudeihefhgfeg feekffeiueevkeeuudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehgrghllhgrthhinhdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihht hidqudeffeehledvvdduiedqvdelhedtgedukeegqdhgrghllhgrthhinheppehfrhgvvg gsshgurdhorhhgsehfrghsthhmrghilhdrtghomh X-ME-Proxy: Feedback-ID: i41414658:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id A1D73364006B; Fri, 2 Feb 2024 21:20:01 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-144-ge5821d614e-fm-20240125.002-ge5821d61 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: <2fac0ac3-ba3a-4bca-b0d4-fafb0c5b75fd@app.fastmail.com> In-Reply-To: References: <2c31ac44-b34b-469c-a6de-fdd927ec2f9e@freebsd.org> Date: Fri, 02 Feb 2024 21:19:41 -0500 From: "Drew Gallatin" To: "Rick Macklem" Cc: "Richard Scheffenegger" , "freebsd-net@FreeBSD.org" , "FreeBSD Transport" , rmacklem@freebsd.org, kp@freebsd.org Subject: Re: Increasing TCP TSO size support Content-Type: multipart/alternative; boundary=40239dadffc4465dbc528566ad3b21da --40239dadffc4465dbc528566ad3b21da Content-Type: text/plain On Fri, Feb 2, 2024, at 9:05 PM, Rick Macklem wrote: > > But the page size is only 4K on most platforms. So while an M_EXTPGS mbuf can hold 5 pages (..from memory, too lazy to do the math right now) and reduces socket buffer mbuf chain lengths by a factor of 10 or so (2k vs 20k per mbuf), the S/G list that a NIC will need to consume would likely decrease only by a factor of 2. And even then only if the busdma code to map mbufs for DMA is not coalescing adjacent mbufs. I know busdma does some coalescing, but I can't recall if it coalesces physcally adjacent mbufs. > > I'm guessing the factor of 2 comes from the fact that each page is a > contiguous segment? Actually, no, I'm being dumb. I was thinking that pages would be split up, but that's wrong. Without M_EXTPGS, each mbuf generated by sendfile (or nfs) would be an M_EXT with a wrapper around a single 4K page. So the scatter/gather list would be exactly the same. The win would be if the pages themselves were contiguous (which they often are), and if the bus_dma mbuf mapping code coalesced those segments, and if the device could handle DMA across a 4K boundary. That's what would get you shorter s/g lists. I think tcp_m_copy() can handle this now, as if_hw_tsomaxsegsize is set by the driver to express how long the max contiguous segment they can handle is. BTW, I really hate the mixing of bus dma restrictions with the hw_tsomax stuff. It always makes my head explode.. Drew --40239dadffc4465dbc528566ad3b21da Content-Type: text/html Content-Transfer-Encoding: quoted-printable

=
On Fri, Feb 2, 2024, at 9:05 PM, Rick Macklem wrote:
<= /div>
> But the pa= ge size is only 4K on most platforms.  So while an M_EXTPGS mbuf ca= n hold 5 pages (..from memory, too lazy to do the math right now) and re= duces socket buffer mbuf chain lengths by a factor of 10 or so (2k vs 20= k per mbuf), the S/G list that a NIC will need to consume would likely d= ecrease only by a factor of 2.  And even then only if the busdma co= de to map mbufs for DMA is not coalescing adjacent mbufs.  I know b= usdma does some coalescing, but I can't recall if it coalesces physcally= adjacent mbufs.

I'm guessing the factor of= 2 comes from the fact that each page is a
contiguous segm= ent?

Actually, no, I'm being d= umb.  I was thinking that pages would be split up, but that's wrong= .  Without M_EXTPGS, each mbuf generated by sendfile (or nfs) would= be an M_EXT with a wrapper around a single 4K page.  So the scatte= r/gather list would be exactly the same.

Th= e win would be if the pages themselves were contiguous (which they often= are), and if the bus_dma mbuf mapping code coalesced those segments, an= d if the device could handle DMA across a 4K boundary.  That's what= would get you shorter s/g lists.

I think tcp_m_copy()= can handle this now, as if_hw_tsomaxsegsize is set by the driver to exp= ress how long the max contiguous segment they can handle is.

BTW, I really hate the mixing of bus dma restrictions = with the hw_tsomax stuff.  It always makes my head explode..

Drew

--40239dadffc4465dbc528566ad3b21da-- From nobody Sat Feb 3 03:15:39 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 4TRd7y5fnTz58tZ7; Sat, 3 Feb 2024 03:15:58 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (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 4TRd7x4nsxz4jcC; Sat, 3 Feb 2024 03:15:57 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oi1-x230.google.com with SMTP id 5614622812f47-3bd4e6a7cb0so1704616b6e.3; Fri, 02 Feb 2024 19:15:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706930156; x=1707534956; 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=o8uCLbNo/R5iSdbdI8CNoNnJR3ftEHgHipU87im0erY=; b=iSePHhC9kqdZbuZ8TrqO4ufw7vo2EuKi9/JxMOSZCwS3K4tisp2uAutAqGY+CCn9Fm 71CWYe/n0H2v9E3fmyAy7UmXEkfVINEPcl5WEp+FLJzSdwyQmlsimRP49+KxWNB8faNR vKFn7MAh1RBNrSCSCKJe5m1Q36RuVCJkoSVkSgS1Klmtslc8S+QLClwEU+Z/+n4N6b6o qAinhHQ9WXgOYjjr+nK3eoQINfN50YSH5Z70fPBlcXoqcDFi6YhsHzoEbMatde8mtwZ3 k3lFWQZwT9JRJLfa/LlqZ6q2WNiUEuFH4d4urZxk7JcB322Z2IFKoJVK6Aj3BlFjazzG Srqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706930156; x=1707534956; 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=o8uCLbNo/R5iSdbdI8CNoNnJR3ftEHgHipU87im0erY=; b=GGKatnJYBI8enrazHpolwuLL0byY3juCU2qs2pxHLzj2/tiIq64ChS/6+CRGUWK6Fy Thr0NyufHn/Qv1m+Genx0/gy/bcpsbZfCWTOk3O/vMSABNTfiIM1wv4M7iQkaynY2xJX Q5xVfTnm2bg/0uqIvRiRpWf6OvlUGqCNPH3PGrBwN/O4n8XVs7RR1El9tQ3tIgl37i6u nM2ruMu+o0dvdILZ7tHeSQa4nCfXyZWoXuhdvUd3Rskp+6kMGpHCJ0lM0qkUeZ+tsrY3 slgWbL9fUeMOhsfeVL9HaVeLX29hNt2RPBHvxvhCgq0oA8BRDMHXPyQuDWd59bMpXUon l+mw== X-Gm-Message-State: AOJu0YymyaOCWDCf5S1lx9A44uX2AhkPJ0e49SZIjuEsKuoWjQQiA7Fq XNzaVbbNKKPxsFnOUsn5t4LhfMkmnJQAelq4apWNIeM0DJ2Y+3LZjyZ+4D5I53lB8YWBExe/ZrQ Wa3R9Wcin1b7fWRih3lfCb0Hv7qc83oQ= X-Google-Smtp-Source: AGHT+IFpaR6MUUSl/y8AbsnDea1G0Xn8sbOmw0h2bN/CwD6kfqQ61IYfBSs1OrEFiwbSA9qsFxYnIQEulqsDvzg0IEI= X-Received: by 2002:a05:6808:ecd:b0:3bd:a088:ab25 with SMTP id q13-20020a0568080ecd00b003bda088ab25mr10842526oiv.50.1706930156190; Fri, 02 Feb 2024 19:15:56 -0800 (PST) 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: <2c31ac44-b34b-469c-a6de-fdd927ec2f9e@freebsd.org> <2fac0ac3-ba3a-4bca-b0d4-fafb0c5b75fd@app.fastmail.com> In-Reply-To: <2fac0ac3-ba3a-4bca-b0d4-fafb0c5b75fd@app.fastmail.com> From: Rick Macklem Date: Fri, 2 Feb 2024 19:15:39 -0800 Message-ID: Subject: Re: Increasing TCP TSO size support To: Drew Gallatin Cc: Richard Scheffenegger , "freebsd-net@FreeBSD.org" , FreeBSD Transport , rmacklem@freebsd.org, kp@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TRd7x4nsxz4jcC 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)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] On Fri, Feb 2, 2024 at 6:20=E2=80=AFPM Drew Gallatin = wrote: > > > > On Fri, Feb 2, 2024, at 9:05 PM, Rick Macklem wrote: > > > But the page size is only 4K on most platforms. So while an M_EXTPGS m= buf can hold 5 pages (..from memory, too lazy to do the math right now) and= reduces socket buffer mbuf chain lengths by a factor of 10 or so (2k vs 20= k per mbuf), the S/G list that a NIC will need to consume would likely decr= ease only by a factor of 2. And even then only if the busdma code to map m= bufs for DMA is not coalescing adjacent mbufs. I know busdma does some coa= lescing, but I can't recall if it coalesces physcally adjacent mbufs. > > I'm guessing the factor of 2 comes from the fact that each page is a > contiguous segment? > > > Actually, no, I'm being dumb. I was thinking that pages would be split u= p, but that's wrong. Without M_EXTPGS, each mbuf generated by sendfile (or= nfs) would be an M_EXT with a wrapper around a single 4K page. So the sca= tter/gather list would be exactly the same. > > The win would be if the pages themselves were contiguous (which they ofte= n are), and if the bus_dma mbuf mapping code coalesced those segments, and = if the device could handle DMA across a 4K boundary. That's what would get= you shorter s/g lists. > > I think tcp_m_copy() can handle this now, as if_hw_tsomaxsegsize is set b= y the driver to express how long the max contiguous segment they can handle= is. Sounds good. I'll give it a try someday soon (April maybe). Thanks for all the good info, rick > > BTW, I really hate the mixing of bus dma restrictions with the hw_tsomax = stuff. It always makes my head explode.. > > Drew > From nobody Sat Feb 3 20:20:47 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 4TS3th4Jjvz58Lmt for ; Sat, 3 Feb 2024 20:21:00 +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 4TS3tf2VNBz46Zk for ; Sat, 3 Feb 2024 20:20:58 +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=OJXJZan+; 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=1706991655; x=1707250855; bh=LDehVr8O5R7RQxstSRkYFa87jtSZYeEv2f81zj0VQkU=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=OJXJZan+oi8Zt1KXo3xN5H/+5UkJENTTZG7xHNS8LnlZA/J7o98M1VDyv44WZGjC9 Bs8Wz0GuIFU7H0keS2/uuSBjrR5r5ShgKzTjbQT4Iy8Sz+FwmvCGyeP/kZS337DT6f /jZSsk8nl9vAwZvCeSuMO6/48wzFWxjB4PDWaDA9Tuj+EeHSGxUXZpQBqtLdM9TZlC 5pZJXkdHI9b5v9SwvgoYbWSINIy+/cGOBPbUmDefohICOlbNC7eWD1+r4asa4Xz5RB WnxZeXOH3S0d8D/u4nPNBeeLbeysgHGekI+xsFp2aMmvd8JFCM4FbE1KvJTvLkgDYV 2Szs71lrkm8rw== Date: Sat, 03 Feb 2024 20:20:47 +0000 To: "freebsd-net@FreeBSD.org" From: Benoit Chesneau Subject: where is happening the development of vpp of freebsd? Message-ID: <5IChPmI-60MZrk24s--GFDo9AHYjgCVtdmQ8iI43RUXjss8-gWTDCAsYeeM1vDBQpqs2_DJd45dD6nfIC5J_eDSSDe4OGo-tCFiADXCuVdU=@enki-multimedia.eu> 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 [-3.40 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; DMARC_POLICY_ALLOW(-0.50)[enki-multimedia.eu,none]; RWL_MAILSPIKE_EXCELLENT(-0.40)[185.70.40.22:from]; R_DKIM_ALLOW(-0.20)[enki-multimedia.eu:s=protonmail2]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[enki-multimedia.eu:+] X-Rspamd-Queue-Id: 4TS3tf2VNBz46Zk I there any public source repository for the development of VPP on FreeBSD?= Any link to follow?=C2=A0 Beno=C3=AEt From nobody Sat Feb 3 21:16:59 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 4TS57k07Btz58Rtc for ; Sat, 3 Feb 2024 21:17:22 +0000 (UTC) (envelope-from thj@freebsd.org) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (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 4TS57j2jkFz4DQ2 for ; Sat, 3 Feb 2024 21:17:21 +0000 (UTC) (envelope-from thj@freebsd.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=messagingengine.com header.s=fm3 header.b="X yvdzcM"; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=freebsd.org (policy=none); spf=softfail (mx1.freebsd.org: 66.111.4.26 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 mailout.nyi.internal (Postfix) with ESMTP id 117DE5C00B3 for ; Sat, 3 Feb 2024 16:17:21 -0500 (EST) Received: from imap47 ([10.202.2.97]) by compute3.internal (MEProxy); Sat, 03 Feb 2024 16:17:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=fm3; t=1706995041; x= 1707081441; bh=q8Hm9DRMDJt/IK+6iDMOcCzENXTYXzQ9lJWdSJZKAiM=; b=X yvdzcMM3dJ7Adx8I6129/wuqbGZ2w/iWofhqDUaAQvgVDcqBJw/4CG1T0N53dntw lUXqidl+bubof+nFmRtLldsuaXesAZHLlwQOtJEdnLHtLGe7nuhySUdbX+GiZ4B7 mIXbkeEa50QgAmFe7vxpk2HxH4DioN/lct6WW605RwQVov0X6wdYF480bnkjvn96 lzF2R8EtrlyYfO8sFYQWKGxZBC94Nd/oef8ZHG7i70o0DDkDVE1ZlZH5TCOCL9mX HLRz7Y//tMY6cRb2JA/QlaW16kDqfPPpoEnThwtCGpHVLJ49pAgWJrMKCAYYM6FJ mt2Xt/FncV4sDLZdvI0+Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrfeduiedgudeghecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgse htqhertderreejnecuhfhrohhmpedfvfhomhculfhonhgvshdfuceothhhjhesfhhrvggv sghsugdrohhrgheqnecuggftrfgrthhtvghrnheptdetffekfeehueekkeetuefhkeegve ffhedtueehjeegtddutdehieffgeelgeeunecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepthhhjhesfhhrvggvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: ib75146ab:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id CBE77A60078; Sat, 3 Feb 2024 16:17:20 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-144-ge5821d614e-fm-20240125.002-ge5821d61 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: <8cd8a722-892e-4931-bf87-ee54ae6af08e@app.fastmail.com> In-Reply-To: <5IChPmI-60MZrk24s--GFDo9AHYjgCVtdmQ8iI43RUXjss8-gWTDCAsYeeM1vDBQpqs2_DJd45dD6nfIC5J_eDSSDe4OGo-tCFiADXCuVdU=@enki-multimedia.eu> References: <5IChPmI-60MZrk24s--GFDo9AHYjgCVtdmQ8iI43RUXjss8-gWTDCAsYeeM1vDBQpqs2_DJd45dD6nfIC5J_eDSSDe4OGo-tCFiADXCuVdU=@enki-multimedia.eu> Date: Sat, 03 Feb 2024 21:16:59 +0000 From: "Tom Jones" To: freebsd-net@freebsd.org Subject: Re: where is happening the development of vpp of freebsd? Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.39 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_SHORT(-1.00)[-0.997]; R_DKIM_ALLOW(-0.20)[messagingengine.com:s=fm3]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : No valid SPF, DKIM not aligned (relaxed),none]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.26:from]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[66.111.4.26:from]; XM_UA_NO_VERSION(0.01)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[messagingengine.com:+]; FREEFALL_USER(0.00)[thj]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; R_SPF_SOFTFAIL(0.00)[~all]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; TO_DOM_EQ_FROM_DOM(0.00)[]; MIME_TRACE(0.00)[0:+] X-Rspamd-Queue-Id: 4TS57j2jkFz4DQ2 On Sat, Feb 3, 2024, at 20:20, Benoit Chesneau wrote: > I there any public source repository for the development of VPP on=20 > FreeBSD? Any link to follow?=C2=A0 > > Beno=C3=AEt I=E2=80=99m working to upstream changes right now and plan to start a de= velopment branch early next week. - Tom From nobody Sun Feb 4 04:21: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 4TSGXy44ptz58vC9 for ; Sun, 4 Feb 2024 04:21:22 +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 4TSGXy1PdVz4smd for ; Sun, 4 Feb 2024 04:21:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1707020482; 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=qx0w07d2IGwCq7N9ma+QovnOs1MFmxrWE6EVQQ5lmwM=; b=NFqzTIZrYZyJVmP6OxalKa0nVBga5j4l8iwID2Yzm4iDELpN++r5Mzh51vr+OrKlR1E/+C s3RI7UYhQTO6eZ4j4hvHtIow622j1pW4NWjXl29JyIFc9A9xChH4wagyDYgrLO9Y72jjDJ mvPd++P8q8RNxNCZBCUyCUqtTUQNYxScQy4buYIKBguYOw/zIfj5T+OkytKU5z9wtUAfLg uWT7mlGSe6vErCOmPw6NV7T9rwBmI7vvQYcdTTYgL0OfSD85xhvDIoH0SHbZdyp4/sBi0x YllTVgg6n6fUh/791ORhIROv7ZD4DA7C9Qsq+s9K1+dTr8z8q0gYN6r/Gmq0Sw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1707020482; a=rsa-sha256; cv=none; b=k7QVPZEhkBaDHcbWdPUDRN1MneJa9eTKpKu9WixDYcReQoVshfv2w20M0swNfv9pt792Lt oT9CQbXIDYYpka6xlrTXeBqb9v8M+N8mTv1NfW7y8OrOVIQHa8MXiwoBElTLfajHy9F/6d i7IUlT2nZudcc4SnVofezhwfs1od6C7dJvwyZf286MlE7MoJPm/CbCQPh3CK0BkMqNz3YG +AwWgyCw+qaacVIWwZcHrpkNsuAgMuk8bgAm3GYz03ZzDvm/UyIlk1IvgR4HsdHw9xS5dP fKqlguwCRq3ywpOVGuifUN1IEVT1i8eRQWHtBJGehNYIfhfGun4qVJzm34UVig== 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 4TSGXy0TpmzjCY for ; Sun, 4 Feb 2024 04:21: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 4144LMUl006304 for ; Sun, 4 Feb 2024 04:21:22 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4144LM49006303 for net@FreeBSD.org; Sun, 4 Feb 2024 04:21: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 276760] vtnet driver incorrectly calculates checksums Date: Sun, 04 Feb 2024 04:21: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: 13.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some 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: 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=3D276760 --- Comment #4 from Zhenlei Huang --- (In reply to crypt47 from comment #0) > but was extreamly slow, when traffic crosses vtnet and VPN interfaces May you please elaborate your setup that how the traffic crosses vtnet and = VPN interfaces ? --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Feb 4 05:50: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 4TSJWZ70hcz593Mx for ; Sun, 4 Feb 2024 05:50:18 +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 4TSJWZ5q05z4yx2 for ; Sun, 4 Feb 2024 05:50:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1707025818; 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=DaWFiW3TPp7gqgedlXGi1lPup6weWHvrjZWEH0PrQ6A=; b=AqXppLh32X351ww80oJusrfcUqAZfApWX66L36FYe5sWyFyzbO/V2HqZsUSgBs0/PKaNo+ a2CvYefB1s4wynnwOWNesjIhv7qlEWCMDCHwQgcHMS1cH42vFzcg2X/SXTaxbXlE3ka+sM cjzHtZWkEGJF+Vy6bl+DrRqg4igdwzmsHjf2zZjH2xxSK0GmXVOU2laOfFH1hkz2zYZGnM LE0iG3rBKbbRlTcUcViC9JhBzoqqP4t1AvFuF0Sl4XNHZU/ukrFwRZ3CcHd++3GX9T7vLR rDdFxbFDSlgodBsKjuhNidRW1Uh+dMdasfgT41rqhIBNRt2hATLdm5Fs63HzqA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1707025818; a=rsa-sha256; cv=none; b=g/kBpqfnuzMgw+bpTUUmJ1yz3Iwy6NFavh5d3+D54oV+g6/3pnZSQufmkb6JMs04Voe19H F6IlWZ1ROhnXkab+xWAqRC3jVg6rA3PnyUYzTEuxibEMSN4EHze801C83g3zZWQPo+AVQ7 erkQH9lVY6hdTEvpAwikdeQ1Yl0fDGZFdSQ8wtecOMUDIUaOr6y4Twej0GyEKuguGaabS7 vm8SIDVSnBNk7fWiCnKeDg9dJTTwNj38lQ+BfOUMEAdbTQP9YHlYv4qtY7fwn7Kd8R2yw9 4DS2nkeGLuflIOj0zjMkdPvlrfGqqLyuKpUeUYUTqFRt7uDPnjud2a9Cm7+Mkw== 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 4TSJWZ4mS7zlbb for ; Sun, 4 Feb 2024 05:50:18 +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 4145oICR060358 for ; Sun, 4 Feb 2024 05:50:18 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4145oIAu060357 for net@FreeBSD.org; Sun, 4 Feb 2024 05:50: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 276760] vtnet driver incorrectly calculates checksums Date: Sun, 04 Feb 2024 05:50: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: 13.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: cryptogranny@gmail.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: attachments.created 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=3D276760 --- Comment #5 from crypt47 --- Created attachment 248169 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D248169&action= =3Dedit port 80 dump --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Feb 4 05:51: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 4TSJY03sPtz593yc for ; Sun, 4 Feb 2024 05:51: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 4TSJY02nNwz50mC for ; Sun, 4 Feb 2024 05:51:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1707025892; 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=iWHm2Eu3BgMZzBKWiTzV3ArdZ9Ju+ISNPIfMCPXOIRs=; b=tg2Q/b54TU/hhrrifS4Gs2zJIC7oTbkfIBWXrmncQOx8PByMMxF8XyAYr3sk23jvKSFRpT YBjAbAcF3HRmVjt9+UrOHAT/hMuI63AFeIbAsMRcyJ5zX5vOnuQZ/cLjNchGsBMt4qX3Rj N3UqaptBQJpQAXRfBmPdeofeOv+C77y4xtl9+U1xS7OhMC+mj+BZ8guBAIxP2IucfvCPja P223WyP6U8nSX7JtSZ6AMpdbFWuumqJuS3w6KCxW1eO9qKu/83AKdNEEJMhRFX4XGVQM8n kW6wYUqpc8Vw3k+IRXZZX1ZVjdjDPXpHsASIyYObGW7LwqSlUtfd/odcfxrKvw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1707025892; a=rsa-sha256; cv=none; b=k8sG7SpkgYGSr7b6kTpvS/qOk6fvSmvAqVIw94xOB2av6t5Ms3099v+ge1mNKDT5mTAumM NWbkuInSe/OfG/iMennw/u+CqVvghWtr4Xgi6OxFTV1vhY3zJqdNn64zbk1AjWb09VhWSZ fpIdX5/OW16xOhT8gnnyeydAA4SEZFk7wzKlZUTI+ob0L4iGigWfsG0G/g2H3mz+WGyvhC eio5ZPrcydT/NC3TI3oQmNelDN7mjzpQgaEE2WfxjvaVAY/JniaqPUR5VajgbhFwk5rRuG JOlNyM1r4HukIjbrdNC/XjvfmWGvjBnasIF3t8GZDmXAXuNijnfZhwxOSh/Ufg== 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 4TSJY01t2FzlYQ for ; Sun, 4 Feb 2024 05:51: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 4145pWxg075005 for ; Sun, 4 Feb 2024 05:51:32 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4145pWdI075004 for net@FreeBSD.org; Sun, 4 Feb 2024 05:51: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 276760] vtnet driver incorrectly calculates checksums Date: Sun, 04 Feb 2024 05:51: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: 13.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: cryptogranny@gmail.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=3D276760 --- Comment #6 from crypt47 --- (In reply to Zhenlei Huang from comment #4) It is very simple. We have one machine "A" with outgoing interface (vtnet0)= and some virtual (like ipsec0 or tun0). We also have another VM "B" in the same network and also vtnet0 interface w= hich has nginx serving FreeBSD ISO file.:) If we directly request the ISO file from "A" works alight. If we request the file via VPN interfaces, we get a lot of retransmissions because packets began to be discarded. I'm attaching the dump file, captured on vtnet0. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Feb 4 05:59:17 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 4TSJjy02s3z594rd for ; Sun, 4 Feb 2024 05:59:18 +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 4TSJjx67snz51hg for ; Sun, 4 Feb 2024 05:59:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1707026357; 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=Dw+bDCsykci8omopLEtxC1JaTKDJj++hRhqyf+GZ5Io=; b=FjTSEaycYVvXAIWB28dF8g17d0ilnZgkoIv5sTTDyRg3e1hwjWsWQUKJ8MclxynyiJMn6l ZcNWaj7YNBe2RlgMJ7hziPmrDXnCueGRDC1C/bmjzEBOXT6cVpC4JH4fiFv6TysJ80170x rd1iqPZQthHwWYrnRcCjcO2aIX1oq5QphX1T0Il37Ds3jY9ek1BAtZqzBZHlU0t1rsyoBD BNLrfgiYHG+NF8NQzU61bPB9OzjQdEQF2i0IaO5mbyjgi8TM0REVW/L3N+Kh4QO1eXy0m+ kHDaeKFctnvGC2DmxLRtG61FD1HOFjc/GE6Z8Nhg967etxhUJ8riAjULja6mfg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1707026357; a=rsa-sha256; cv=none; b=lrMuQcg6X/e+jDmrrXr85J0u2jsjB98J3vEsXe+79Ihanx1jidWgv2EDkuiqz0O1Sfe05B xEdHdhe56otQrQEnLz51B7sFWBkmdX7eSW+E3FRtRt4OZfEx+DxSZsui4VW6rlr2c2CeVm COf0dErX2ufnWhe1P3p11i4hrNxQu4LrQHMAAYgs/8rPouk8fotJePIqAXv93MZirDHA8z mtmE5z3vLprCd1GFcmXB5eWBmAxRe6PEpbvl+cdwaFiMKBou2MpQ3Uc8WhgZ6XBQGlElNT teZGR8NK7SMbIUjKu/kF/0Tv4A5hqYwLRutV9Sw8pHNRkKJJJQWHAW1q8w6ePw== 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 4TSJjx5Fc9zlTn for ; Sun, 4 Feb 2024 05:59:17 +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 4145xH7v007643 for ; Sun, 4 Feb 2024 05:59:17 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4145xHSE007642 for net@FreeBSD.org; Sun, 4 Feb 2024 05:59:17 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 276760] vtnet driver incorrectly calculates checksums Date: Sun, 04 Feb 2024 05:59:17 +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: 13.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: cryptogranny@gmail.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=3D276760 --- Comment #7 from crypt47 --- If you view the attached 80.dump file with Wireshark and check "validate the TCP checksum" option, it will complain about server (10.0.0.53) packets. Ca= n't say how much it's relevant, because it's not the server with VPN setup. It = may be some Wireshark miscalculation. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Feb 4 06:06:16 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 4TSJt109LZz59547 for ; Sun, 4 Feb 2024 06:06:17 +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 4TSJt05lx5z52mG for ; Sun, 4 Feb 2024 06:06:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1707026776; 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=//kkStiC3mS16S3w3m5To1ycYRtJGHhBxj+jD2A2SP0=; b=ufC5ZFp6O/1BMp5lfy5ADfgrfwod2H/YyqoBrygPsRUfw04a20ud45AvW6i1ypsyC/IBPL rrIx4wp1blznlAhr/uiRGXDjnwGeuJpOrzqcVbWmZsdh2cmiTLz12+MqRlx3kxSWE1qwUj /bIIgSytMx7D1SOQoIdfaFA89PSXpBTEqvGVII7y+jEVj4n79HW6KXdmI6gwT//Ep16gvF zLAtcymFOT4mzNtbVikap6gKs3RssTCwGAfsknjjoH62vyiaAV7jR+f/frxZtKCZTK4bWz rMPeINFnLofpjybK8mt1FKpZW/Tlogw9gE7lRoczd17LuPDEiKKAvszxxfnhqw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1707026776; a=rsa-sha256; cv=none; b=ZSGQEo5PUSZ7CmY1YBZZVuhYHev+7DRdSz1dCNH5Yli3+yZBHt5ZQVG/1wjpAD82go7NWt HHGB0+rGyIqDL5n6kimt4uAyEcemUUth6oshhekkaatlbCsFc/dps8R04bRdesmxp9opLD r/jy0KwyC84mTZ1z9Tk6RxfWyzRJqGwynKgOfbSmUi9WySm7bHXwChaM3vRl2szjvEzeSP hJSEhXF+BdUflmxXUZIXrfd/UWQk7WdeHNXEaBJlzFMqJUqHKXACDkr+mI1Bk/sOC5SZQS mfMrHgywnGra7me7V4m6VPMR/zoM4BDPRewxzyu+sXcvm1sDlwlCNPjrOfVgyQ== 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 4TSJt04ff8zlZ1 for ; Sun, 4 Feb 2024 06:06:16 +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 41466Gxl051298 for ; Sun, 4 Feb 2024 06:06:16 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 41466GWL051294 for net@FreeBSD.org; Sun, 4 Feb 2024 06:06:16 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 276760] vtnet driver incorrectly calculates checksums Date: Sun, 04 Feb 2024 06:06:16 +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: 13.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: cryptogranny@gmail.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=3D276760 --- Comment #8 from crypt47 --- As for the ipfw configuration, I don't want to post it in full, but I use=20 ipfw_f add 10 reass all from any to any in // ASSEMBLING in the beginning. Some nat translation later. Nothing special. Also mss fix= is used for IPsec, but it can't be relevant. Breaks with OpenVPN too. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Feb 4 09:52:14 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 4TSPvF1vGHz59Rly for ; Sun, 4 Feb 2024 09:52:41 +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 4TSPvD6365z49Wc for ; Sun, 4 Feb 2024 09:52:40 +0000 (UTC) (envelope-from benoitc@enki-multimedia.eu) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enki-multimedia.eu; s=protonmail2; t=1707040357; x=1707299557; bh=+rQGYIghZ5s/ejz9v2RB+ZGEwcEbbfX6QEfoPIZYowU=; 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=IWlGSHtrQCAOeJd0zszjmPO2EmalVYV6yMj2QxZV0NyKbsRPI2vEPIo4K4wtlqQGg dT1qWVFu2TqOsQAnv5W0V7VTdXFd1DmXI1WlGBvT0S22LeuuYtzwdbtbTyHT7KrxwR 74nHfEgtzfUgHGiWoa4iMn/BRY1bU8fV2+Y7X5D2lwo1txlApus9sl9Nxszw0bWjA/ kRVZjeLKa7WzPyZ+8g6D6VkxeRPreXC/DV2aP62kUNliPm4WZlXlDVSKGChLdxybFX a+pNaQIzz6DDL9elCm3BI99MJjEtsatNZ9Wo2THCbWDJNdQTUXHOciXONxIcl94AEl IXCEwHB9FZHQg== Date: Sun, 04 Feb 2024 09:52:14 +0000 To: Tom Jones From: Benoit Chesneau Cc: freebsd-net@freebsd.org Subject: Re: where is happening the development of vpp of freebsd? Message-ID: In-Reply-To: <8cd8a722-892e-4931-bf87-ee54ae6af08e@app.fastmail.com> References: <5IChPmI-60MZrk24s--GFDo9AHYjgCVtdmQ8iI43RUXjss8-gWTDCAsYeeM1vDBQpqs2_DJd45dD6nfIC5J_eDSSDe4OGo-tCFiADXCuVdU=@enki-multimedia.eu> <8cd8a722-892e-4931-bf87-ee54ae6af08e@app.fastmail.com> 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-Rspamd-Queue-Id: 4TSPvD6365z49Wc 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:62371, ipnet:185.70.40.0/24, country:CH] Awesome :) Thanks for taking care of it! Beno=C3=AEt Chesneau Sent with Proton Mail secure email. On Saturday, February 3rd, 2024 at 22:16, Tom Jones wrote= : >=20 > On Sat, Feb 3, 2024, at 20:20, Benoit Chesneau wrote: >=20 > > I there any public source repository for the development of VPP on > > FreeBSD? Any link to follow? > >=20 > > Beno=C3=AEt >=20 >=20 > I=E2=80=99m working to upstream changes right now and plan to start a dev= elopment branch early next week. >=20 > - Tom From nobody Sun Feb 4 09:58:26 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 4TSQ2351ZXz59SJR for ; Sun, 4 Feb 2024 09:58:35 +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) client-signature RSA-PSS (4096 bits)) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TSQ2318h1z4C9Q for ; Sun, 4 Feb 2024 09:58:35 +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=iwNBlfHX; 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=1707040713; x=1707299913; bh=vNchfilNGSc4I7EMx1a0DXWUDewuEb8DapsIxm8yddQ=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=iwNBlfHXE/TW33dMj+2xQCaNOv/1I1we2Dx3D5eIUne+RNp7kvy1o0ovrPvMz/EXC RvI9d5Bv5wCnVeBVoiviQVg73W6M3q6A/HUg7Qjn2oN4X9fOnvdblsdFQSNLBBSQxW ezsFz3e6gM/Y763P/BWX3ywJvnvgkiIR4V5aYjXBENvhhOr7M8fsW1fFutPNmc518f 4zo2TbhPHqPvIeVqeFhAwPB4ewfZvibnby/fG6f8JhuniWOffO99gaPYa41Lvwa4Ig So6z/bnyuh6Vy9PAU/B8lr8oGqV3txACOIOdw1qcNeI/svYOy8gqnVU7OIxmtneEHG QQBZTrj79nxSA== Date: Sun, 04 Feb 2024 09:58:26 +0000 To: "freebsd-net@FreeBSD.org" From: Benoit Chesneau Subject: Anyway way to set an interface IP not reassigned during netif ? 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: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.40 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[enki-multimedia.eu,none]; RWL_MAILSPIKE_EXCELLENT(-0.40)[185.70.40.22:from]; R_DKIM_ALLOW(-0.20)[enki-multimedia.eu:s=protonmail2]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[enki-multimedia.eu:+] X-Rspamd-Queue-Id: 4TSQ2318h1z4C9Q Im' using the machine as a gateway and use one of the interface as an OOB a= ccess to the applications. I should be able to launch automated commands to= re-configure the applications an other network interfaces from this OOB in= terface.=C2=A0 The issue I have is that when I update the rc.conf and launch the command `= service netif restart` and same for the `routing` it will reset all interfa= ces and reassign the configuration to them. Which disconnect the client mak= ing the upgrade. What would be the way the way to prevent it?=C2=A0 For now I'm thinking to set the interfaces and routing =C2=A0separatly but = hen I miss the flexibility of rc.conf . Is there another way to do it and e= nsure an interface won't be resetted? Beno=C3=AEt From nobody Sun Feb 4 17:13:05 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 4TSbgb4rSsz58PFN for ; Sun, 4 Feb 2024 17:13:15 +0000 (UTC) (envelope-from divyanshvn@zohomail.in) Received: from sender-pp-o94.zoho.in (sender-pp-o94.zoho.in [103.117.158.94]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4TSbgY5MPDz4pZf for ; Sun, 4 Feb 2024 17:13:13 +0000 (UTC) (envelope-from divyanshvn@zohomail.in) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=zohomail.in; spf=pass (mx1.freebsd.org: domain of divyanshvn@zohomail.in designates 103.117.158.94 as permitted sender) smtp.mailfrom=divyanshvn@zohomail.in; arc=pass ("zohomail.in:s=zohoarc:i=1") ARC-Seal: i=1; a=rsa-sha256; t=1707066787; cv=none; d=zohomail.in; s=zohoarc; b=YcdYsggE1q9cBb1Ho4aWnu27qTIbo7A/iSr4ExNI2uGnqGwqA9euRy1Fcn8ZaV9jITd+QQkb0rX/7yLaLwf0S5wqG31NpIQzZtW0aj1Vxf4nS5tKU4bDr5yw5FQgoSUIR8w7WR/o3CFxABbAERDhKaSRO3Q+97IM+QLuDpkFWbY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.in; s=zohoarc; t=1707066787; h=Content-Type:Date:Date:From:From:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To:Cc; bh=qXpJq+mFhEazNcoMG8J9I37ja7m+HLbjtYCMa3Wbc/w=; b=e/OXkAly/m/vCEgc/CJLqw0fXjq6bkoFu4NDZRBr1/VHgda6br2NJ5cEarX26UIwV8L8vfK+phw/LKLkVTJMGqW81yRzcHrCK2Blxy/wcdy6JwFTFUFn2wtS5e7gwt+yXrCRcaXqb778gESCQPJycKYoKTlAwOATlEgymr//9SA= ARC-Authentication-Results: i=1; mx.zohomail.in; spf=pass smtp.mailfrom=divyanshvn@zohomail.in; dmarc=pass header.from= Received: from mail.zoho.in by mx.zoho.in with SMTP id 1707066785715285.6800428490993; Sun, 4 Feb 2024 22:43:05 +0530 (IST) Received: from [49.207.218.219] by mail.zoho.in with HTTP;Sun, 4 Feb 2024 22:43:05 +0530 (IST) Date: Sun, 04 Feb 2024 22:43:05 +0530 From: "divyansh.nankani" To: "net" Message-Id: <18d751bffa6.4434daac65629.196624564669687745@zohomail.in> In-Reply-To: Subject: Guidance regarding GSoC projects 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="----=_Part_191312_1019387937.1707066785702" Importance: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.59 / 15.00]; ARC_ALLOW(-1.00)[zohomail.in:s=zohoarc:i=1]; NEURAL_HAM_SHORT(-1.00)[-0.995]; NEURAL_HAM_MEDIUM(-0.99)[-0.987]; NEURAL_HAM_LONG(-0.81)[-0.813]; DMARC_POLICY_ALLOW(-0.50)[zohomail.in,reject]; R_SPF_ALLOW(-0.20)[+ip4:103.117.158.0/24:c]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:56201, ipnet:103.117.158.0/23, country:IN]; RCPT_COUNT_ONE(0.00)[1]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[net@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[103.117.158.94:from] X-Rspamd-Queue-Id: 4TSbgY5MPDz4pZf ------=_Part_191312_1019387937.1707066785702 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi ,=C2=A0 I am intending to participate in GSoC for FreeBSD this year. I need a bit o= f help navigating where to start contributing to FreeBSD for issues/feature= s specifically related to the GSoC projects I am targeting :=C2=A0 - Improve netgraph concurrency=C2=A0 - Implement MPLS support for FreeBSD I am also interested in=C2=A0UFS4fuse: support FreeBSD's UFS2 with fusefs (= with rust)=C2=A0but there is no mentor assigned for this project on the pro= ject ideas page. I will be really grateful if you can help me out with this. Thanks, Divyansh ------=_Part_191312_1019387937.1707066785702 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Hi , 
I am intending to participa= te in GSoC for FreeBSD this year. I need a bit of help navigating where to = start contributing to FreeBSD for issues/features specifically related to t= he GSoC projects I am targeting : 
- Improve netgraph = concurrency 
- Implement MPLS support for FreeBSD

I am also interested in UFS4fuse: support FreeBSD's UF= S2 with fusefs (with rust) but there is no mentor ass= igned for this project on the project ideas page.
I will be really g= rateful if you can help me out with this.

Thanks,
Divyansh


------=_Part_191312_1019387937.1707066785702-- From nobody Sun Feb 4 21:00:33 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 4TShjt09bfz58ngR for ; Sun, 4 Feb 2024 21:00:34 +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 4TShjs3kYpz4Jlw for ; Sun, 4 Feb 2024 21:00:33 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1707080433; 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=3V8VHIMRYgjZ+tpibhPKIskv3XK6f94bSaWYez62OTw=; b=eouCPAEER3UWUextzBnzKBAU+tLUeAFcRGE2u1ydAU8Bu76vMtV6e+tEsKu59OgYtmX2Zt cqsVSVeRj5koq9UV74LPiCpVRLj/R3W2vmh1tWvUBEsigGS7TpzEfq5YO27fM2eUzPNW8m IDRxgSk2XMDb0dV9RVDAGVvFbupQ1p3q8sUN4fBH6HmuYOQYlj608KYyLhw1EgFL4rxFIz 5ZNN6iF6jmJAUC4VZi0ETUbJpNg8AscV+0eSf5RpiHPXEuvE+2SaGJSFjGcmV3A9bvxE32 Q/vCfFF5TnsgOUakOzE3JyjCcu3FeX/XIq09WRlvK+IUFxGeJPmTdYUWOlKL4A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1707080433; a=rsa-sha256; cv=none; b=F7FKRF7h5RCJGAWOHmpKtCkZraoFyDu/NAtYynUpGjeuTOuFq5FiuSvinOgfxqIVQcsFqz Pn3vGOTepLP5o4wINMJrgVf++Gll3KIVcBEQHda/HwLXdW3R60YHbapUNqwg3wSymsQP1U L21h77Lt/oa8jB9MPG4+M9g4qPm9vHZRd19G1Qk8aWamqWMLceIIBgssINo5sMCgVTHy/9 BA/JK9/l3DAU1IG0WWxllZ14HpfnZj7AzoU197gHDpImGTpAQxxPprc45Vcq6mlUXKpJ+V 7fHUmH2+nX1OBy7PXPyCHKuczTy/OlMNy3pHjYlTKjLTAkaft0Q+/AuM+WKdSw== 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 4TShjs2qyBz1C3L for ; Sun, 4 Feb 2024 21:00:33 +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 414L0XpZ029529 for ; Sun, 4 Feb 2024 21:00:33 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 414L0X7H029528 for net@FreeBSD.org; Sun, 4 Feb 2024 21:00:33 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202402042100.414L0X7H029528@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, 4 Feb 2024 21:00:33 +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="17070804333.f31A4FF2.24290" Content-Transfer-Encoding: 7bit --17070804333.f31A4FF2.24290 Date: Sun, 4 Feb 2024 21:00:33 +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 ------------+-----------+--------------------------------------------------- In Progress | 275774 | IPv4 Mapper address problem New | 254445 | cloned_interfaces="bridge0" does not respect net. Open | 166724 | if_re(4): watchdog timeout 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 20 problems total for which you should take action. --17070804333.f31A4FF2.24290 Date: Sun, 4 Feb 2024 21:00:33 +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
------------+-----------+---------------------------------------------------
In Progress |    275774 | IPv4 Mapper address problem
New         |    254445 | cloned_interfaces="bridge0" does not respect net.
Open        |    166724 | if_re(4): watchdog timeout
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 

20 problems total for which you should take action.
--17070804333.f31A4FF2.24290--