From owner-freebsd-net@freebsd.org Sun Jun 4 01:07:06 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9C4DBBFC5EF for ; Sun, 4 Jun 2017 01:07:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8A978836D3 for ; Sun, 4 Jun 2017 01:07:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v54176Tv005236 for ; Sun, 4 Jun 2017 01:07:06 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 219428] em network driver broken in current Date: Sun, 04 Jun 2017 01:07:06 +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: regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: gitdev@kippona.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-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 MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 01:07:06 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219428 --- Comment #6 from gitdev --- Created attachment 183187 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D183187&action= =3Dedit debug output Debug output for r319481 on amd64 panic: Assertion adapter->tx_num_queues > 0 failed at /usr/src/sys/dev/e1000/if_em.c:2664 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Jun 4 06:48:16 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B441AFC254 for ; Sun, 4 Jun 2017 06:48:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 78A2F67984 for ; Sun, 4 Jun 2017 06:48:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v546mF7C005936 for ; Sun, 4 Jun 2017 06:48:16 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 213814] AWS/EC2: no egress traffic stats on ixv(4) xn(4) Date: Sun, 04 Jun 2017 06:48:15 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: IntelNetworking, needs-qa, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? X-Bugzilla-Changed-Fields: priority short_desc cc assigned_to flagtypes.name keywords 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 MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 06:48:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213814 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|--- |Normal Summary|AWS/EC2: no egress traffic |AWS/EC2: no egress traffic |stats on ixv(4) |stats on ixv(4) xn(4) CC| |freebsd-virtualization@Free | |BSD.org Assignee|freebsd-virtualization@Free |freebsd-net@FreeBSD.org |BSD.org | Flags| |mfc-stable11? Keywords| |needs-qa, regression Status|New |Open --- Comment #11 from Kubilay Kocak --- Re-assign to more appropriate ML (freebsd-net), cc'ing original ML (virtualization). --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Jun 4 21:00:05 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B21D7BEEBC6 for ; Sun, 4 Jun 2017 21:00:05 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A805784170 for ; Sun, 4 Jun 2017 21:00:05 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v54L01IA013858 for ; Sun, 4 Jun 2017 21:00:05 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201706042100.v54L01IA013858@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-net@FreeBSD.org Subject: Problem reports for freebsd-net@FreeBSD.org that need special attention Date: Sun, 04 Jun 2017 21:00:05 +0000 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 21:00:05 -0000 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 | 165622 | [ndis][panic][patch] Unregistered use of FPU in k In Progress | 206581 | bxe_ioctl_nvram handler is faulty New | 204438 | setsockopt() handling of kern.ipc.maxsockbuf limi New | 205592 | TCP processing in IPSec causes kernel panic New | 206053 | kqueue support code of netmap causes panic New | 213410 | [carp] service netif restart causes hang only whe New | 215874 | [patch] [icmp] [mbuf_tags] teach icmp_error() opt New | 217748 | sys/dev/ixgbe/if_ix.c: PVS-Studio: Assignment to Open | 173444 | socket: IPV6_USE_MIN_MTU and TCP is broken Open | 193452 | Dell PowerEdge 210 II -- Kernel panic bce (broadc Open | 194485 | Userland cannot add IPv6 prefix routes Open | 194515 | Fatal Trap 12 Kernel with vimage Open | 199136 | [if_tap] Added down_on_close sysctl variable to t Open | 202510 | [CARP] advertisements sourced from CARP IP cause Open | 206544 | sendmsg(2) (sendto(2) too?) can fail with EINVAL; Open | 211031 | [panic] in ng_uncallout when argument is NULL Open | 211962 | bxe driver queue soft hangs and flooding tx_soft_ Open | 218653 | Intel e1000 network link drops under high network 18 problems total for which you should take action. From owner-freebsd-net@freebsd.org Mon Jun 5 00:08:11 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 495B0BF2F65 for ; Mon, 5 Jun 2017 00:08:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3706F66187 for ; Mon, 5 Jun 2017 00:08:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v5508Bum046587 for ; Mon, 5 Jun 2017 00:08:11 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 219699] Issue with IPv6 and neighbor notification Date: Mon, 05 Jun 2017 00:08:11 +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: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rkoberman@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-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 MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 00:08:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219699 --- Comment #9 from rkoberman@gmail.com --- (In reply to Paul G Webster from comment #8) That would explain it. I am very surprised that Linux does not use the link-local address for routing information. That was one of the main reason= for the link-local implementation in IPv6. Can someone confirm that Linux does not use link-local as the default NDP communication connection? Yes, ebtables (on linux) should always allow link-local. No, all routing is= not over link-local. Protocols that communicate to non-adjacent nodes (e.g. BGP) cannot use link-local. Glad you tracked this down. You saved the next guy problems. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Jun 5 14:06:52 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3F5EAF9CC7 for ; Mon, 5 Jun 2017 14:06:52 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 960037F540 for ; Mon, 5 Jun 2017 14:06:52 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-oi0-x22f.google.com with SMTP id o65so134190474oif.1 for ; Mon, 05 Jun 2017 07:06:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XO+m8BoxO4Pcmtgsl4oYmUQagvk2WAR6FGUFPe330ew=; b=EdriPRsKJMdg+GnB7zNd4q3dtucV8MomqhGUyNsNmspNerkIGf2jel08aBYo3BEB2p PHik7me53ubUidorTDb2E36ITv81L8h+bDSHmzWTxHAwvAr5CgxEVtwqkZgEfhop43Ps 9XDmYZfAA9FRP3EfgSo8I2bN+/TPwlrp44E1nF22DSEzkIw8xjaNW90QP3S8IxtnSQg6 flztMOBsHzpIDOaZOG6vMgEZZuqDYFkasjuq89scW7eeEGckyTiddvOIrkCrvTHy6g11 aAwam4s+FrqgN1UYtuYjOay++LPZ9sSxVrhvH2JriOwQD991pls1EHDZtaNlm1sSsA2H sVlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XO+m8BoxO4Pcmtgsl4oYmUQagvk2WAR6FGUFPe330ew=; b=jqGqObqfXUjJyNhSkoD0jm4c4OZSLv22q0aBU3HZrZMP/t37vj7UMOOBMA3YXP/VQU BTvF3r4jLc+KC5Pt2SSMXxQhF/FpC6peCGJ+tvDNYbuHUK70vC2Dgz1XXJlPmRygBF1y B1rHwPbXugW7CQ/4zaiZ9VucP2mckRxVpNZ544G1PHS2zqQNQroZrbQcBEWEDrXGBH8o Qb3ka2FOvluHz1fuiWVGYAsqPZoN+b4lufQb6FWUVIJCjGHG90fCXdfXJO4uZS8n1dDB NB+/PL1Ny6hGJlIxo1O4B1y7YQ2M3OtHVaF7HdLrcdn/c/6qXJmL2xxqzjXuDscfXDkB eHBQ== X-Gm-Message-State: AODbwcAYixJTP1il5Cy+C2N5lWBRzk1vmpSZlo0eyogzkXSQ9hQbbyzI s4bXN/23o1qiGsJqTje0aMgRYNZ37tFV X-Received: by 10.157.58.102 with SMTP id j93mr2729811otc.147.1496671611528; Mon, 05 Jun 2017 07:06:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.17.49 with HTTP; Mon, 5 Jun 2017 07:06:51 -0700 (PDT) In-Reply-To: <592FC60A.1030308@omnilan.de> References: <5926FFDB.7040900@omnilan.de> <592F20A0.4020702@omnilan.de> <592FC60A.1030308@omnilan.de> From: Vincenzo Maffione Date: Mon, 5 Jun 2017 16:06:51 +0200 Message-ID: Subject: Re: ovs-netmap forgotten? To: Harry Schmalzbauer Cc: freebsd-net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 14:06:52 -0000 Hi Harry, I've done some investigation on this issue (just for fun) , and I think I may have found the issue. When using vlan interfaces, netmap use the emulated adapter, as the "vlan" driver is not netmap-enabled (and it cannot be). To intercept RX packets, netmap replaces the "if_input" function pointer field in the kernel "struct ifnet" (the struct representing a network interface). Note that you have an instance of "struct ifnet" for em0 (physical NIC), and a different instance for each VLAN cloned interface (e.g. "vlan100") on em0. If you put vlan100 in netmap mode, netmap will replace the if_input of vlan100, and not the if_input of em0. So far, this is an expected behaviour= . Unfortunately, I see in the code here https://github.com/freebsd/freebsd/blob/master/sys/net/if_vlan.c#L1244-L124= 5 that when VLAN driver intercepts the RX packet coming from the underlying interface (e.g. em0 in our example), the em0 if_input is used rather than the vlan100 if_input. In terms of code, we have (*ifp->if_input)(ifv->ifv_ifp, m); rather than (*ifv->ifv_ifp->if_input)(ifv->ifv_ifp, m); Since em0 if_input is not replaced, netmap does not intercept it and you don't see it in your application, e.g. # pkt-gen -i vlan100 -f rx will see nothing. Now, I think that normally ifv->ifv_ifp->if_input =3D=3D ifp->if_input, so = this may explain why the code is written like that (to avoid the additional pointer dereferencing). This is not the case for netmap, where ifv->ifv_ifp->if_input !=3D ifp->if_input when em0 xor vlan100 are in netmap mode. You may try to recompile the kernel with that change and see if you can see packets coming on vlan100 with pkt-gen. I recommend you always doing tests with pkt-gen before trying to use vale-ctl -a. Cheers, Vincenzo 2017-06-01 9:45 GMT+02:00 Harry Schmalzbauer : > Bez=C3=BCglich Vincenzo Maffione's Nachricht vom 01.06.2017 00:39 (localt= ime): > > Hi Harry, > > OVS integration with netmap is very patchy and Linux only. Most > > importantly, it is not the right way to go, for a number of reasons. > > The real solution would be to integrate netmap into OVS would be to > > follow the DPDK-OVS approach: this means implementing the switching > > logic completely in userspace, in this case using the netmap API. This > > has not been implemented nor sketched so far. > > > > `vale-ctl -n valeXXX:YYY` just creates a persistent VALE port (YYY) > > attached to the VALE switch XXX. > > There is no difference with an ephemeral VALE port, apart for the fact > > that the persistent one is visible with ifconfig. > > > > It does not really make sense to attach a VLAN interface to VALE, since > > the VLAN driver does not have netmap support, so you lose all the > > advantage of using netmap and VALE. > > In your case the best solution I see is to write a custom netmap > > application that forwards the packets between a netmap-supported NIC an= d > > one or more VMs, doing the VLAN stripping in software. > > Thanks again, Vincenzo, for your highly appreciated support! > > I can only concur to your proposed solution. Problem is, I don't speak > any programmin language well (besides sh maybe) and have abosuletely no > budget/time to do any work out on my C skills (which I'd love to do) ;-) > > So ovs-netmap wasn't the right direction, but the difference between > em0+if_brdige+vmnet|virtio-net+vtnet and vale:em0|vale:guest+vtnet is > noticable. I haven't done any measuring, but just performing typical > admin jobs via cli (ssh into the bhyve-guest, whith resorces via NFS > (v4)) behave completely different =E2=80=93 human-noticable much more sna= ppy in > the vale:guest case! > I don't think this enormous efficiency advantge is soleley caused by > em0-netmap/ring connection; More important, in the > vale:em0|vale:guest+vtnet case, I gain excellent inter-vm efficiency > (and much higher attainable performance of course, which is not crucial > at the moment; but efficiency is!). > Now replacing vale:em0 by vale:vlan0 will surely destroy one big > efficiency advantage, but I still benefit from excellent inter-vm > efficiency and most likely some small efficiency advantage left over the > if_bridge picture. > Also, ptnet is a very interisting area of optimization which is easy to > explore with the vale:vlan scenario. > > In another post I described that the vale:vlan path doesn't work, while > vale:em0 (the parent) with everything else untouched does work. > Dou you think it's possible to fix the vale:vlan coupling without netmap > experts setting up a test environment? > > Thanks, > > -harry > > --=20 Vincenzo Maffione From owner-freebsd-net@freebsd.org Mon Jun 5 18:25:18 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E53ADAFEC3E for ; Mon, 5 Jun 2017 18:25:18 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8386765333 for ; Mon, 5 Jun 2017 18:25:18 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v55IPFYI044771; Mon, 5 Jun 2017 20:25:15 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id A70737A0; Mon, 5 Jun 2017 20:25:14 +0200 (CEST) Message-ID: <5935A20A.6040000@omnilan.de> Date: Mon, 05 Jun 2017 20:25:14 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Vincenzo Maffione CC: freebsd-net Subject: Re: ovs-netmap forgotten? References: <5926FFDB.7040900@omnilan.de> <592F20A0.4020702@omnilan.de> <592FC60A.1030308@omnilan.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Mon, 05 Jun 2017 20:25:15 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 18:25:19 -0000 Bezüglich Vincenzo Maffione's Nachricht vom 05.06.2017 16:06 (localtime): > Hi Harry, > I've done some investigation on this issue (just for fun) , and I think I > may have found the issue. > > When using vlan interfaces, netmap use the emulated adapter, as the "vlan" > driver is not netmap-enabled (and it cannot be). > To intercept RX packets, netmap replaces the "if_input" function pointer > field in the kernel "struct ifnet" (the struct representing a network > interface). > Note that you have an instance of "struct ifnet" for em0 (physical NIC), > and a different instance for each VLAN cloned interface (e.g. "vlan100") on > em0. > If you put vlan100 in netmap mode, netmap will replace the if_input of > vlan100, and not the if_input of em0. So far, this is an expected behaviour. > > Unfortunately, I see in the code here > > https://github.com/freebsd/freebsd/blob/master/sys/net/if_vlan.c#L1244-L1245 > > that when VLAN driver intercepts the RX packet coming from the underlying > interface (e.g. em0 in our example), the em0 if_input is used rather than > the vlan100 if_input. > > In terms of code, we have > (*ifp->if_input)(ifv->ifv_ifp, m); > rather than > (*ifv->ifv_ifp->if_input)(ifv->ifv_ifp, m); > Since em0 if_input is not replaced, netmap does not intercept it and you > don't see it in your application, e.g. > > # pkt-gen -i vlan100 -f rx > > will see nothing. > > Now, I think that normally ifv->ifv_ifp->if_input == ifp->if_input, so this > may explain why the code is written like that (to avoid the additional > pointer dereferencing). > This is not the case for netmap, where ifv->ifv_ifp->if_input != > ifp->if_input when em0 xor vlan100 are in netmap mode. > > You may try to recompile the kernel with that change and see if you can see > packets coming on vlan100 with pkt-gen. > I recommend you always doing tests with pkt-gen before trying to use > vale-ctl -a. NICE :-) Thank you very much for your effort and impressive reading-only analysis. Maybe one has to be used to ifv ifp and companion variables, or I can't see _the_ simplicity of the code or everybody else is geniuous... First quick test shows you're right and this tiny diff solves a decent share of my (ESXi-replacing) problems: --- src/sys/net/if_vlan.c.orig 2017-06-05 17:39:27.770574000 +0200 +++ src/sys/net/if_vlan.c 2017-06-05 17:39:21.550278000 +0200 @@ -1234,7 +1234,7 @@ if_inc_counter(ifv->ifv_ifp, IFCOUNTER_IPACKETS, 1); /* Pass it back through the parent's input routine. */ - (*ifp->if_input)(ifv->ifv_ifp, m); + (*ifv->ifv_ifp->if_input)(ifv->ifv_ifp, m); } static int Will do real-world tests tommorrow. Unrelated to the vlan-netmap issue, more topic-related: Last little (completely non-academic) test showed unfortunately that "vtnet|virtio-net<-vale:guestif->netmapIF" can't compete with "vmx3f|vmxnet3<-ESXivSwitch->sameHWif". The latter consumes no noticable CPU consumption when NFS-copying big files via 1GbE, like on native host (which leaves the machine 99-100% idle @108MB/s). Running the same guest with the same task on bhyve causes ~20% CPU utilization; @1GbE :-( Also there was no significant difference between vale(4) and if_bridge(4) with that workload (little IPp/s on saturated 1GbE PHY). Most likely the lack of offloading features, and thus causing many more interrupts in the guest than with vmxf3's TSO capability, is the cause. Haven't done any inter-VM "real-world" tests yet, where vale(4) will strike back... So to achive my goal, replacing my ESXi setups, I'd need your quick help again to port vmxnet3 ;-) /joking Hope ptnet can help out here, at least for FreeBSD guests, but as far as I could see, when merging netmap from HEAD to stable/11, (updated diff applicable after r319182 was available here too: ftp://ftp.omnilan.de/pub/FreeBSD/OmniLAN/misc/), bhyve(8) doesn't support ptnet yet. Is there any specific reason why ptnetmap-memdev (https://svnweb.freebsd.org/socsvn/soc2016/vincenzo/head/usr.sbin/bhyve/pci_ptnetmap_netif.c) hasn't been commited to HEAD? Does anybody have an idea if there is any vmnet/vtnet companion (in development stage) providing offloading features, reducing interrupt wastings? Another question, better addressed to virtualization@ but I remember cross-posting is to avoid: I never tried to understand why vmx3f seems to work without using interrupts at all, as opposed to vmx(4), but maybe it is possible to do the same for vtnet(4)? Thanks, -harry From owner-freebsd-net@freebsd.org Mon Jun 5 19:02:15 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8529FAFF744 for ; Mon, 5 Jun 2017 19:02:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 733DF66689 for ; Mon, 5 Jun 2017 19:02:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v55J2FxE023449 for ; Mon, 5 Jun 2017 19:02:15 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 219746] Renaming (ifconfig(8)) tap(4) misses its character special device name Date: Mon, 05 Jun 2017 19:02:15 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.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: freebsd-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 MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 19:02:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219746 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Jun 6 06:40:41 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5FCC8BF772F for ; Tue, 6 Jun 2017 06:40:41 +0000 (UTC) (envelope-from hmurray@megapathdsl.net) Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by mx1.freebsd.org (Postfix) with ESMTP id 4BC3D805D3 for ; Tue, 6 Jun 2017 06:40:40 +0000 (UTC) (envelope-from hmurray@megapathdsl.net) Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 4F3FE406063; Mon, 5 Jun 2017 23:40:39 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: freebsd-net@freebsd.org cc: Hal Murray From: Hal Murray Subject: Anybody using SO_BINTIME with IPv6? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Jun 2017 23:40:39 -0700 Message-Id: <20170606064039.4F3FE406063@ip-64-139-1-69.sjc.megapath.net> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 06:40:41 -0000 I'm cleaning up some code. SO_BINTIME works with IPv4. SO_TIMESTAMP works with IPv4 and IPv6. But SO_BINTIME doesn't work with IPv6. setsockopt works, but recvmsg doesn't return any cmsg data. If this is a known problem, I'll just use SO_TIMESTAMP and accept the reduced resolution. If somebody has a working example, I'll work harder on finding a bug/quirk and/or making a simple test case. -- These are my opinions. I hate spam. From owner-freebsd-net@freebsd.org Tue Jun 6 09:45:36 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9254EBFB582 for ; Tue, 6 Jun 2017 09:45:36 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 53817DF3 for ; Tue, 6 Jun 2017 09:45:36 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-ot0-x234.google.com with SMTP id a2so12741731oth.2 for ; Tue, 06 Jun 2017 02:45:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Fsht4L51y044ttDxRGHMLmOsxi4IPGQClIRVoAH8XEw=; b=nrm/M726ukX+7K7moMEDqsi8yMBnkrIxgzKgPYTpxAQn/0+ll1PPPrMkOJ7sK1Ztvu OJ1YrVXmb0nT13ZH1KYsbeLNTeXfcRfv+JgY38+XgI1CR4So2xiPhUyavhDw44HA0UH+ f2wgsjX3PE8udQ4zgkinxr2PGwVXz2Dkvi0d0I6hzfGkX/aefhxvwXDlY5g7YRVU79Qh lZLNayqtzqjVkOaHAxx6hZDw/Ayh7qIbvzlzSIgvg08QiFQbE7l3K323642mQByqgnGx SzrPwR8D6N4l0ldRTUFK14959xpjaUFy1+KXV1N8f8AnMFssH7SF3VVn+ZbRmLZnCI1F cSPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Fsht4L51y044ttDxRGHMLmOsxi4IPGQClIRVoAH8XEw=; b=ClIxEwNwWkQSFPLdzX4P9Zfvr9Rbo6Zyqq4H9h4YGoGofZMFpb6If7BwDLaH1tWsxs SKcPo+ogQPNiL0cLbzJO7OVHmx/cwujiRgIF/7IHTmTQByap0mdG5ICYEV29eJn0xyPL 74FD6VfL1pqCGv7mGei1hABaXHGONihwNZ5IBHMwmn7mKUDD7RkOzg2XbEwDnt2/eZc9 uvI629NZFFNhKjb+e+BH28UEubYzYRyad9ZlOZRpCWkdoUcgl+jfyrWrF9WPaALbJRYm cgE0WDK/uMxvc5OOsvma8hBHGZKeMHth6Kav/X7tBU5Cs3z7WCksG62A2GPKHjR5O56J 2yWA== X-Gm-Message-State: AODbwcBpluWsPzyf3EMbZ9WKn94p2iy+z9Yo1bhwRYjwSXzS1LqEuVED fooLUTDfLaG6y8VO4EU5GPpa2uo8SW/x X-Received: by 10.157.23.133 with SMTP id j5mr12408219otj.37.1496742335357; Tue, 06 Jun 2017 02:45:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.17.49 with HTTP; Tue, 6 Jun 2017 02:45:34 -0700 (PDT) In-Reply-To: <5935A20A.6040000@omnilan.de> References: <5926FFDB.7040900@omnilan.de> <592F20A0.4020702@omnilan.de> <592FC60A.1030308@omnilan.de> <5935A20A.6040000@omnilan.de> From: Vincenzo Maffione Date: Tue, 6 Jun 2017 11:45:34 +0200 Message-ID: Subject: Re: ovs-netmap forgotten? To: Harry Schmalzbauer Cc: freebsd-net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 09:45:36 -0000 2017-06-05 20:25 GMT+02:00 Harry Schmalzbauer : > Bez=C3=BCglich Vincenzo Maffione's Nachricht vom 05.06.2017 16:06 (localt= ime): > > Hi Harry, > > I've done some investigation on this issue (just for fun) , and I > think I > > may have found the issue. > > > > When using vlan interfaces, netmap use the emulated adapter, as the > "vlan" > > driver is not netmap-enabled (and it cannot be). > > To intercept RX packets, netmap replaces the "if_input" function pointe= r > > field in the kernel "struct ifnet" (the struct representing a network > > interface). > > Note that you have an instance of "struct ifnet" for em0 (physical NIC)= , > > and a different instance for each VLAN cloned interface (e.g. "vlan100"= ) > on > > em0. > > If you put vlan100 in netmap mode, netmap will replace the if_input of > > vlan100, and not the if_input of em0. So far, this is an expected > behaviour. > > > > Unfortunately, I see in the code here > > > > https://github.com/freebsd/freebsd/blob/master/sys/net/ > if_vlan.c#L1244-L1245 > > > > that when VLAN driver intercepts the RX packet coming from the underlyi= ng > > interface (e.g. em0 in our example), the em0 if_input is used rather th= an > > the vlan100 if_input. > > > > In terms of code, we have > > (*ifp->if_input)(ifv->ifv_ifp, m); > > rather than > > (*ifv->ifv_ifp->if_input)(ifv->ifv_ifp, m); > > Since em0 if_input is not replaced, netmap does not intercept it and yo= u > > don't see it in your application, e.g. > > > > # pkt-gen -i vlan100 -f rx > > > > will see nothing. > > > > Now, I think that normally ifv->ifv_ifp->if_input =3D=3D ifp->if_input,= so > this > > may explain why the code is written like that (to avoid the additional > > pointer dereferencing). > > This is not the case for netmap, where ifv->ifv_ifp->if_input !=3D > > ifp->if_input when em0 xor vlan100 are in netmap mode. > > > > You may try to recompile the kernel with that change and see if you can > see > > packets coming on vlan100 with pkt-gen. > > I recommend you always doing tests with pkt-gen before trying to use > > vale-ctl -a. > > NICE :-) Thank you very much for your effort and impressive reading-only > analysis. > Maybe one has to be used to ifv ifp and companion variables, or I can't > see _the_ simplicity of the code or everybody else is geniuous... > > First quick test shows you're right and this tiny diff solves a decent > share of my (ESXi-replacing) problems: > > --- src/sys/net/if_vlan.c.orig 2017-06-05 17:39:27.770574000 +0200 > +++ src/sys/net/if_vlan.c 2017-06-05 17:39:21.550278000 +0200 > @@ -1234,7 +1234,7 @@ > if_inc_counter(ifv->ifv_ifp, IFCOUNTER_IPACKETS, 1); > > /* Pass it back through the parent's input routine. */ > - (*ifp->if_input)(ifv->ifv_ifp, m); > + (*ifv->ifv_ifp->if_input)(ifv->ifv_ifp, m); > } > > static int > > Will do real-world tests tommorrow. > We may ask the VLAN developers whether that ifp->if_input is really necessary or we can replace it with ifv->ifv_ifp->if_input. > > Unrelated to the vlan-netmap issue, more topic-related: > Last little (completely non-academic) test showed unfortunately that > "vtnet|virtio-net<-vale:guestif->netmapIF" > can't compete with > "vmx3f|vmxnet3<-ESXivSwitch->sameHWif". > The latter consumes no noticable CPU consumption when NFS-copying big > files via 1GbE, like on native host (which leaves the machine 99-100% > idle @108MB/s). > Running the same guest with the same task on bhyve causes ~20% CPU > utilization; @1GbE :-( Yes, because of the offloadings on the physical NIC and offloading support in the vmx*. > > Also there was no significant difference between vale(4) and > if_bridge(4) with that workload (little IPp/s on saturated 1GbE PHY). > Most likely the lack of offloading features, and thus causing many more > interrupts in the guest than with vmxf3's TSO capability, is the cause. > Haven't done any inter-VM "real-world" tests yet, where vale(4) will > strike back... > Correct. if_tap does not support offloadings at all. ptnet/VALE supports them, but there is no support for netmap physical ports. > > So to achive my goal, replacing my ESXi setups, I'd need your quick help > again to port vmxnet3 ;-) /joking > > Hope ptnet can help out here, at least for FreeBSD guests, but as far as > I could see, when merging netmap from HEAD to stable/11, (updated diff > applicable after r319182 was available here too: > ftp://ftp.omnilan.de/pub/FreeBSD/OmniLAN/misc/), bhyve(8) doesn't > support ptnet yet. ptnet driver is already in HEAD. Support for bhyve is not yet in HEAD, but available here https://github.com/vmaffione/freebsd/tree/ptnet-head in the ptnet-head branch. > Is there any specific reason why ptnetmap-memdev > (https://svnweb.freebsd.org/socsvn/soc2016/vincenzo/head/ > usr.sbin/bhyve/pci_ptnetmap_netif.c) > hasn't been commited to HEAD? > That's a very good question. bhyve code for ptnet has been ready for a year, but I'm still waiting for the bhyve maintainers to commit it. I'll raise the issue again at BSDCan over the week-end ( https://www.bsdcan.org/2017/schedule/events/814.en.html). I hope I'll find people willing to commit this! > > Does anybody have an idea if there is any vmnet/vtnet companion (in > development stage) providing offloading features, reducing interrupt > wastings? > > Another question, better addressed to virtualization@ but I remember > cross-posting is to avoid: > I never tried to understand why vmx3f seems to work without using > interrupts at all, as opposed to vmx(4), but maybe it is possible to do > the same for vtnet(4)? > The only way to avoid interrupts at all is to do busy waiting or polling, but nobody does that for general purpose networking because you waste CPU or artificially increase latency. So vmx* does use interrupts. The way to go to optimize the TCP performance between a VM and the external physical network is to follow the QEMU virtio-net + vhost-net approach on Linux ( http://blog.vmsplice.net/2011/09/qemu-internals-vhost-architecture.html), which is similar to what ptnet does. However, offloading support if if_tap is also needed (Linux does that). Cheers, Vincenzo > Thanks, > > -harry > > --=20 Vincenzo Maffione From owner-freebsd-net@freebsd.org Tue Jun 6 10:00:17 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B7A28BFB96A for ; Tue, 6 Jun 2017 10:00:17 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 51E3415BB for ; Tue, 6 Jun 2017 10:00:17 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v569xVtE061644; Tue, 6 Jun 2017 11:59:31 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (s1.omnilan.de [217.91.127.234]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id F02F58B8; Tue, 6 Jun 2017 11:59:30 +0200 (CEST) Message-ID: <59367CF5.9080101@omnilan.de> Date: Tue, 06 Jun 2017 11:59:17 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Vincenzo Maffione CC: freebsd-net Subject: Re: ovs-netmap forgotten? References: <5926FFDB.7040900@omnilan.de> <592F20A0.4020702@omnilan.de> <592FC60A.1030308@omnilan.de> <5935A20A.6040000@omnilan.de> In-Reply-To: <5935A20A.6040000@omnilan.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Tue, 06 Jun 2017 11:59:31 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 10:00:17 -0000 Bezüglich Harry Schmalzbauer's Nachricht vom 05.06.2017 20:25 (localtime): > Bezüglich Vincenzo Maffione's Nachricht vom 05.06.2017 16:06 (localtime): > … > First quick test shows you're right and this tiny diff solves a decent > share of my (ESXi-replacing) problems: > > --- src/sys/net/if_vlan.c.orig 2017-06-05 17:39:27.770574000 +0200 > +++ src/sys/net/if_vlan.c 2017-06-05 17:39:21.550278000 +0200 > @@ -1234,7 +1234,7 @@ > if_inc_counter(ifv->ifv_ifp, IFCOUNTER_IPACKETS, 1); > > /* Pass it back through the parent's input routine. */ > - (*ifp->if_input)(ifv->ifv_ifp, m); > + (*ifv->ifv_ifp->if_input)(ifv->ifv_ifp, m); > } > > static int > > Will do real-world tests tommorrow. To share my observations: Attaching if_vlan(4) to vale(4) works with the above modification, as long as vlanhwtag is _not_ disabled, at least with igb(4) and (em4). Having other offloadings enabled or disabled (regardless if it's on parent or vlan-clone) doesn't matter, disabling vlanhwtag on the parent leads to congested parent if there's mor etraffic than console... I haven't done any tracking if it's caused by TCP windows scaling e.g. nor tried to ask the code, because I do want vlanhwtagging enabled and that's what works so far :-) This is also true for if_vlan(4) interfaces which have if_lagg(0) as parent, and also for both types of vale(4) attaching, hoststack-detached (-a) or hoststack-attached (-h). So far very nice :-) But there's a interrupt multiplication noticeable (at the host). My simple NFS-copying test causes ~10ki/s at one igb(4) queue when invoked on the host, with mtu 1500. Same invocation in the guest, with vlan-vale setup, causes 30ki/s average (with high discrepancy, 20-40k). Might it be possible that if_vlan(4) influences interrupt moderation capabilities? Vincenzo, thanks for your answers to my questions, which I read during writing of this - stripping them here. -harry From owner-freebsd-net@freebsd.org Tue Jun 6 10:54:33 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A90EEBFD215 for ; Tue, 6 Jun 2017 10:54:33 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3EBEF32FB for ; Tue, 6 Jun 2017 10:54:33 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v56AsVjk062955; Tue, 6 Jun 2017 12:54:31 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (s1.omnilan.de [217.91.127.234]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 2F0C88C8; Tue, 6 Jun 2017 12:54:31 +0200 (CEST) Message-ID: <593689DA.8000304@omnilan.de> Date: Tue, 06 Jun 2017 12:54:18 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Vincenzo Maffione CC: freebsd-net Subject: Re: ovs-netmap forgotten? References: <5926FFDB.7040900@omnilan.de> <592F20A0.4020702@omnilan.de> <592FC60A.1030308@omnilan.de> <5935A20A.6040000@omnilan.de> <59367CF5.9080101@omnilan.de> In-Reply-To: <59367CF5.9080101@omnilan.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Tue, 06 Jun 2017 12:54:31 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 10:54:33 -0000 Bezüglich Harry Schmalzbauer's Nachricht vom 06.06.2017 11:59 (localtime): … > Having other offloadings enabled or disabled (regardless if it's on > parent or vlan-clone) doesn't matter, … I must correct myself! At least when it comes to host-stack traffic. Keeping offloadings enabled on the vale-attached interface doesn't interfere with vale(4) traffic, but with host traffic. Since I don't know anything about the implementation of offloadings, I assumed it would affect vale packets, but the real effect is the opposite of what I expected, so the statment above is simply wrong, sorry. -harry From owner-freebsd-net@freebsd.org Tue Jun 6 15:42:01 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04405BEF63F for ; Tue, 6 Jun 2017 15:42:01 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward1j.cmail.yandex.net (forward1j.cmail.yandex.net [IPv6:2a02:6b8:0:1630::14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9AD0A70F00; Tue, 6 Jun 2017 15:42:00 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp1h.mail.yandex.net (smtp1h.mail.yandex.net [84.201.187.144]) by forward1j.cmail.yandex.net (Yandex) with ESMTP id 60B1F210DD; Tue, 6 Jun 2017 18:41:47 +0300 (MSK) Received: from smtp1h.mail.yandex.net (localhost.localdomain [127.0.0.1]) by smtp1h.mail.yandex.net (Yandex) with ESMTP id B02358C0C02; Tue, 6 Jun 2017 18:41:45 +0300 (MSK) Received: by smtp1h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id rIx0QCJcmG-fiCK4vKw; Tue, 06 Jun 2017 18:41:44 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1496763704; bh=7ytKCuIlIdxP3p7/Yx9R0Uvxvmoj1ZROGQ6Oy3JwIxs=; h=Subject:To:References:Cc:From:Message-ID:Date:In-Reply-To; b=Udg2fl8ucRRoRzlAbtMT7kVR+sWONl3+rG77Ggubx7Um0RcJZ5blN/AA1KAzyJbBV pXe0oMDHo6fSPcChro7j3dleQnbumuSEdjz8fDd2cBtbzqMBn1RkB+iVfT1oLEKR1p b5QKWvxitPw4zDv1Qsr+qh+TDp5NBs/4IIFzapSA= Authentication-Results: smtp1h.mail.yandex.net; dkim=pass header.i=@yandex.ru X-Yandex-Suid-Status: 1 0,1 0,1 0 Subject: Re: Anybody using SO_BINTIME with IPv6? To: Hal Murray , freebsd-net@freebsd.org References: <20170606064039.4F3FE406063@ip-64-139-1-69.sjc.megapath.net> Cc: Maxim Sobolev From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Message-ID: Date: Tue, 6 Jun 2017 18:39:37 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <20170606064039.4F3FE406063@ip-64-139-1-69.sjc.megapath.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="D6A1w9K94f36pXb9Mcf8r7rLQUH1JxuA2" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 15:42:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --D6A1w9K94f36pXb9Mcf8r7rLQUH1JxuA2 Content-Type: multipart/mixed; boundary="I0I8RosmtdR4x8sqXQAAMpGxPA8vV4Q5G"; protected-headers="v1" From: "Andrey V. Elsukov" To: Hal Murray , freebsd-net@freebsd.org Cc: Maxim Sobolev Message-ID: Subject: Re: Anybody using SO_BINTIME with IPv6? References: <20170606064039.4F3FE406063@ip-64-139-1-69.sjc.megapath.net> In-Reply-To: <20170606064039.4F3FE406063@ip-64-139-1-69.sjc.megapath.net> --I0I8RosmtdR4x8sqXQAAMpGxPA8vV4Q5G Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 06.06.2017 09:40, Hal Murray wrote: >=20 > I'm cleaning up some code. SO_BINTIME works with IPv4. SO_TIMESTAMP w= orks=20 > with IPv4 and IPv6. >=20 > But SO_BINTIME doesn't work with IPv6. setsockopt works, but recvmsg d= oesn't=20 > return any cmsg data. >=20 > If this is a known problem, I'll just use SO_TIMESTAMP and accept the r= educed=20 > resolution. If somebody has a working example, I'll work harder on fin= ding a=20 > bug/quirk and/or making a simple test case. Hi, it seems like a bug, that is easy to fix, but Maxim has already implemented another option in this patch https://reviews.freebsd.org/D9171 --=20 WBR, Andrey V. Elsukov --I0I8RosmtdR4x8sqXQAAMpGxPA8vV4Q5G-- --D6A1w9K94f36pXb9Mcf8r7rLQUH1JxuA2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAlk2zLkACgkQAcXqBBDI oXof/AgArQL3xslukPoScHlBb+IagKHKxL97U6XWFbdFVhfw70jwRm/kMAIc9lT7 PqhvJ2HrwY3U8nRNr+xSM47+Jz+OIZYQQU2bdZGOWl5f22ggZ2KnNTdhCgbQyp5+ sBCKTkIX4tQT3DxnXIODSI3eEUp/Plfyv8UNvfVnJ5BiXc3J5QblN0LnpgxKXxkc hRJIOfjgyImEw/FndUHYIaUeXU3BtrCFvRbns5TPQKN40HIo5xtpuwMQZYbsI73R +hyhfOCQKdq0WZCiYUxjqjNNU5UHuGNVHfhNTyz+9llP0H1khV14/Zu02fb68uDT CCLzd/xxq64Fo+K3n3Q7AZlNk/2Hgw== =8W5r -----END PGP SIGNATURE----- --D6A1w9K94f36pXb9Mcf8r7rLQUH1JxuA2-- From owner-freebsd-net@freebsd.org Tue Jun 6 15:54:27 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 189A7BEF8EE for ; Tue, 6 Jun 2017 15:54:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 06E21713F6 for ; Tue, 6 Jun 2017 15:54:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v56FsQld082912 for ; Tue, 6 Jun 2017 15:54:26 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 219703] System freeze when creating bridge over vlan over lagg over ixgbe Date: Tue, 06 Jun 2017 15:54:27 +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: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-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 MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 15:54:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219703 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ae@FreeBSD.org --- Comment #1 from Andrey V. Elsukov --- There were a couple of fixes related to lagg, vlan, and bridge locking. Can= you test your setup with stable/11 or some recent 11.1-PRERELEASE snapshot? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Jun 6 20:27:40 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 008A9BF4302 for ; Tue, 6 Jun 2017 20:27:40 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B3D0479405 for ; Tue, 6 Jun 2017 20:27:39 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-ua0-x233.google.com with SMTP id q15so14387191uaa.2 for ; Tue, 06 Jun 2017 13:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XoZcLaI3xH23omgzt88riuUeBV61eFXdDJiApPW0big=; b=fRQGcwSFP6VLAB3Y+C1F65ME7GNtbkIkle8n4QJOTqb3iidkE1kdkvGcdr2igV0JX2 1NdaXt9ZUQWQ0KeNwEeN8wJkT8+dWtN3NtzYBsfJO71MAYKVwf7ByNr426JR8nW8jMKH BOGTtWoV/cVPCOfYY3qQm2FRFj5rgb83wp9J+KCOr2Ts/mPareROQEE/ZevW+78CLFBH e9U/7IWLulGwS0tNm3avDUxLSPQZFyxGXYW0GEjEBLEzkbp03uBugXMhoTMgnJhwgxnP bSIaUOVAxbrTEL4GjIUpxOgI0K9YPLxIdKXWrLe7Yp8n+Bm+7ZCOZYzLnroeD7Uw9dPq qiKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XoZcLaI3xH23omgzt88riuUeBV61eFXdDJiApPW0big=; b=KZsAvUFYQGurOg1TT0oWKEZR2pquUGirQbKaSM+Zmr539PX+QYNX8y7LyuPKW/xNcf ynL99gnwtysP4xZX4LJTMW8+96bsir53N8FYqBdaslhezocoL7Jwz9ilR35h1FfZcvsb /ciChT2c7Jtmf82SsH0uYx/m8Zg3iUgyTuSw+8ln4nxtGuUIe9TEktHkpDpySxI3swFP sZ5yDZV1XrapRAIHSGjRvIhw5CLCXYc9t/iBtVZ2fJgVBTp25OgnEc+Kw1pQA9HXr+kE T2Xk9zqk2gu+WQoBRFTYd+sG453MxREtPA7bt+z5aGlrgHUFX+DI1L5BXFoJQ9GxWUA+ OV9Q== X-Gm-Message-State: AODbwcDaZzmnjOMGoyC+sVqh4XDoAmpzITTt4BFVc2v7N6aYEDpGNqv4 E4MkZp57gTYOZWx34o0W+6FHa6d6EXOx X-Received: by 10.159.60.82 with SMTP id w18mr13268364uah.19.1496780858603; Tue, 06 Jun 2017 13:27:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.193 with HTTP; Tue, 6 Jun 2017 13:27:37 -0700 (PDT) Received: by 10.176.18.193 with HTTP; Tue, 6 Jun 2017 13:27:37 -0700 (PDT) In-Reply-To: References: <20170606064039.4F3FE406063@ip-64-139-1-69.sjc.megapath.net> From: Maxim Sobolev Date: Tue, 6 Jun 2017 13:27:37 -0700 Message-ID: Subject: Re: Anybody using SO_BINTIME with IPv6? To: "Andrey V. Elsukov" Cc: Hal Murray , FreeBSD Net Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 20:27:40 -0000 SO_BINTIME was ENOTSUPP with IPv6 from the day one. In general I think it's safe to advise to use SO_TIMESTAMP instead, which is also more flexible interface. I'd suggest SO_BINTIME is marked as obsoleting one instead. -Max On Tue, Jun 6, 2017 at 8:39 AM, Andrey V. Elsukov wrote: > On 06.06.2017 09:40, Hal Murray wrote: > > > > I'm cleaning up some code. SO_BINTIME works with IPv4. SO_TIMESTAMP > works > > with IPv4 and IPv6. > > > > But SO_BINTIME doesn't work with IPv6. setsockopt works, but recvmsg > doesn't > > return any cmsg data. > > > > If this is a known problem, I'll just use SO_TIMESTAMP and accept the > reduced > > resolution. If somebody has a working example, I'll work harder on > finding a > > bug/quirk and/or making a simple test case. > > Hi, > > it seems like a bug, that is easy to fix, but Maxim has already > implemented another option in this patch > https://reviews.freebsd.org/D9171 > > -- > WBR, Andrey V. Elsukov > > -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts Tel (Canada): +1-778-783-0474 <(778)%20783-0474> Tel (Toll-Free): +1-855-747-7779 <(855)%20747-7779> Fax: +1-866-857-6942 <(866)%20857-6942> Web: http://www.sippysoft.com MSN: sales@sippysoft.com Skype: SippySoft From owner-freebsd-net@freebsd.org Tue Jun 6 20:45:42 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B7ED8BF465B for ; Tue, 6 Jun 2017 20:45:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9BD5F79AD7 for ; Tue, 6 Jun 2017 20:45:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v56Kjgiw015637 for ; Tue, 6 Jun 2017 20:45:42 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 219703] System freeze when creating bridge over vlan over lagg over ixgbe Date: Tue, 06 Jun 2017 20:45:42 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: olivier@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-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 MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 20:45:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219703 Olivier Cochard changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |olivier@freebsd.org --- Comment #2 from Olivier Cochard --- I didn't have a 11.0-RELEASE, but I didn't reach to reproduce this problem = on 10.3-RELEASE neither on a 11-stable (r319622). I've got the same chipset: [root@R1]~# pciconf -lv ix0 ix0@pci0:21:0:0: class=3D0x020000 card=3D0x00038086 chip=3D0x10fb808= 6 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82599ES 10-Gigabit SFI/SFP+ Network Connection' class =3D network subclass =3D ethernet [root@R1]~# pciconf -lv ix1 ix1@pci0:21:0:1: class=3D0x020000 card=3D0x00038086 chip=3D0x10fb808= 6 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82599ES 10-Gigabit SFI/SFP+ Network Connection' class =3D network subclass =3D ethernet Then I've tried to reproduce your script: #!/bin/sh set -eu iter=3D0 while true; do lagg_if=3D$(ifconfig lagg create) ifconfig $lagg_if laggproto lacp laggport ix0 laggport ix1 10.0.10.17/24 bridge_if=3D$(ifconfig bridge create) ifconfig $lagg_if description something up vlan_if=3D$(ifconfig vlan create) ifconfig $vlan_if vlandev $lagg_if vlan 4 description something up ifconfig $bridge_if addm $vlan_if up iter=3D$((iter + 1)) echo "iteration $iter, and still online" ifconfig $bridge_if destroy ifconfig $vlan_if destroy ifconfig $lagg_if destroy done But it works: [root@R1]~# sh /tmp/crash.sh (...) iteration 785, and still online iteration 786, and still online iteration 787, and still online iteration 788, and still online iteration 789, and still online iteration 790, and still online ^C --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed Jun 7 10:20:33 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55200C08C43 for ; Wed, 7 Jun 2017 10:20:33 +0000 (UTC) (envelope-from hmurray@megapathdsl.net) Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by mx1.freebsd.org (Postfix) with ESMTP id 3D00E6E13C for ; Wed, 7 Jun 2017 10:20:32 +0000 (UTC) (envelope-from hmurray@megapathdsl.net) Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 8C44C406063; Wed, 7 Jun 2017 03:20:26 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Maxim Sobolev cc: FreeBSD Net , Hal Murray From: Hal Murray Subject: Re: Anybody using SO_BINTIME with IPv6? In-Reply-To: Message from Maxim Sobolev of "Tue, 06 Jun 2017 13:27:37 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 Jun 2017 03:20:26 -0700 Message-Id: <20170607102026.8C44C406063@ip-64-139-1-69.sjc.megapath.net> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 10:20:33 -0000 sobomax@sippysoft.com said: > SO_BINTIME was ENOTSUPP with IPv6 from the day one. Thanks. Is that a literal ENOTSUPP? Should I get an error from setsockopt? Or is that just shorthand for never-got-implemented? Do you want a bug report? If nothing else, the man page should be updated. Just curious... Why wasn't SO_BINTIME implemented for IPv6? Since it works for IPv4 and SO_TIMESTAMP works for IPv4 and IPv6 I'd expect it would be easy to copy a few lines of code. -- These are my opinions. I hate spam. From owner-freebsd-net@freebsd.org Wed Jun 7 14:21:05 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6BC99C6EBD0 for ; Wed, 7 Jun 2017 14:21:05 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0A2AA75A71 for ; Wed, 7 Jun 2017 14:21:04 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v57EL24H080952 for ; Wed, 7 Jun 2017 16:21:02 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (s1.omnilan.de [217.91.127.234]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 3D656B1C; Wed, 7 Jun 2017 16:21:02 +0200 (CEST) Message-ID: <59380BC1.7090300@omnilan.de> Date: Wed, 07 Jun 2017 16:20:49 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: FreeBSD Net Subject: panic after LOR, 2nd netmap_mem2.c, 1st vm_fault.c Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Wed, 07 Jun 2017 16:21:02 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 14:21:05 -0000 lock order reversal: (sleepable after non-sleepable) 1st 0xfffff8007519a960 vm object (vm object) @ /usr/local/share/deploy-tools/RELENG_11/src/sys/vm/vm_fault.c:572 2nd 0xfffff8003299b000 (d)->nm_mtx ((d)->nm_mtx) @ /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_mem2.c:577 stack backtrace: #0 0xffffffff805e7900 at witness_debugger+0x70 #1 0xffffffff805e77f3 at witness_checkorder+0xe23 #2 0xffffffff80591f4e at _sx_xlock+0x5e #3 0xffffffff8042275a at netmap_mem2_ofstophys+0x2a #4 0xffffffff8041f3ab at netmap_dev_pager_fault+0x3b #5 0xffffffff8082d834 at dev_pager_getpages+0x74 #6 0xffffffff80856d2a at vm_pager_get_pages+0x4a #7 0xffffffff8083aa92 at vm_fault_hold+0xa52 #8 0xffffffff80839ff5 at vm_fault+0x75 #9 0xffffffff8088048f at trap_pfault+0xff #10 0xffffffff8087fc38 at trap+0x348 #11 0xffffffff808645d1 at calltrap+0x8 KDB: stack backtrace: #0 0xffffffff805ca4b7 at kdb_backtrace+0x67 #1 0xffffffff8058a3f6 at vpanic+0x186 #2 0xffffffff8058a473 at panic+0x43 #3 0xffffffff8056b564 at __mtx_assert+0xb4 #4 0xffffffff80544780 at knlist_add+0x20 #5 0xffffffff8041ead0 at netmap_kqfilter+0x110 #6 0xffffffff804657f7 at devfs_kqfilter_f+0x77 #7 0xffffffff80542a0b at kqueue_register+0x78b #8 0xffffffff80543432 at kqueue_kevent+0x92 #9 0xffffffff80543336 at kern_kevent_fp+0x96 #10 0xffffffff8054324f at kern_kevent+0x9f #11 0xffffffff80543058 at sys_kevent+0x138 #12 0xffffffff80880dda at amd64_syscall+0x57a #13 0xffffffff808648bb at Xfast_syscall+0xfb #0 doadump (textdump=) at pcpu.h:222 #1 0xffffffff80589e70 in kern_reboot (howto=260) at /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_shutdown.c:366 #2 0xffffffff8058a430 in vpanic (fmt=, ap=) at /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_shutdown.c:759 #3 0xffffffff8058a473 in panic (fmt=) at /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_shutdown.c:690 #4 0xffffffff8056b564 in __mtx_assert (c=0x0, what=0, file=0x0, line=0) at /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_mutex.c:1000 #5 0xffffffff80544780 in knlist_add (knl=0xfffffe000a055450, kn=0xfffff8026d097e80, islocked=1) at /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_event.c:2089 #6 0xffffffff8041ead0 in netmap_kqfilter (dev=, kn=0xfffff8026d097e80) at /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_freebsd.c:1354 #7 0xffffffff804657f7 in devfs_kqfilter_f (fp=0xfffff8001faf8780, kn=0xfffff8026d097e80) at /usr/local/share/deploy-tools/RELENG_11/src/sys/fs/devfs/devfs_vnops.c:837 #8 0xffffffff80542a0b in kqueue_register (kq=0xfffff8001a65c000, kev=0xfffffe045b4dc650, td=0xfffff8014ca71000, waitok=) at /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_event.c:1334 #9 0xffffffff80543432 in kqueue_kevent (kq=0xfffff8001a65c000, td=0xfffff8014ca71000, nchanges=4, nevents=, k_ops=0xfffffe045b4dc8a0, timeout=) at /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_event.c:1019 #10 0xffffffff80543336 in kern_kevent_fp (td=0xfffff8014ca71000, fp=, nchanges=4, nevents=, k_ops=, timeout=) at /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_event.c:1050 #11 0xffffffff8054324f in kern_kevent (td=0xfffff8014ca71000, fd=7, nchanges=4, nevents=0, k_ops=0xfffffe045b4dc8a0, timeout=0x0) at /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_event.c:993 #12 0xffffffff80543058 in sys_kevent (td=0xfffff8014ca71000, uap=0xfffffe045b4dca30) at /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_event.c:925 #13 0xffffffff80880dda in amd64_syscall (td=0xfffff8014ca71000, traced=0) at subr_syscall.c:135 #14 0xffffffff808648bb in Xfast_syscall () at /usr/local/share/deploy-tools/RELENG_11/src/sys/amd64/amd64/exception.S:396 #15 0x000000080122813a in ?? () Sorry, again me, again helpless without you. This is on r319032, stable/11 with netmap merged from HEAD. Since I was advised to replace netmap with github sources, I thought it may be beneficial to get the various HEAD-fixes as well. Seems it's beyond my scope doing such things. Does anybody have a quick idea if it's easily fixable, or a complicated issue, possibly caused due to MFC boch? Thanks, -harry From owner-freebsd-net@freebsd.org Wed Jun 7 16:28:17 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E514FC78EAE for ; Wed, 7 Jun 2017 16:28:17 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7A2EE79DF1 for ; Wed, 7 Jun 2017 16:28:17 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v57GSEbh083003 for ; Wed, 7 Jun 2017 18:28:14 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (s1.omnilan.de [217.91.127.234]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 4BAD8B48; Wed, 7 Jun 2017 18:28:14 +0200 (CEST) Message-ID: <59382991.8000502@omnilan.de> Date: Wed, 07 Jun 2017 18:28:01 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: FreeBSD Net Subject: Re: panic after LOR, 2nd netmap_mem2.c, 1st vm_fault.c References: <59380BC1.7090300@omnilan.de> In-Reply-To: <59380BC1.7090300@omnilan.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: ACL 129 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Wed, 07 Jun 2017 18:28:14 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 16:28:18 -0000 Bezüglich Harry Schmalzbauer's Nachricht vom 07.06.2017 16:20 (localtime): > lock order reversal: (sleepable after non-sleepable) > 1st 0xfffff8007519a960 vm object (vm object) @ > /usr/local/share/deploy-tools/RELENG_11/src/sys/vm/vm_fault.c:572 > 2nd 0xfffff8003299b000 (d)->nm_mtx ((d)->nm_mtx) @ > /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_mem2.c:577 > stack backtrace: > #0 0xffffffff805e7900 at witness_debugger+0x70 > #1 0xffffffff805e77f3 at witness_checkorder+0xe23 > #2 0xffffffff80591f4e at _sx_xlock+0x5e > #3 0xffffffff8042275a at netmap_mem2_ofstophys+0x2a > #4 0xffffffff8041f3ab at netmap_dev_pager_fault+0x3b > #5 0xffffffff8082d834 at dev_pager_getpages+0x74 > #6 0xffffffff80856d2a at vm_pager_get_pages+0x4a > #7 0xffffffff8083aa92 at vm_fault_hold+0xa52 > #8 0xffffffff80839ff5 at vm_fault+0x75 > #9 0xffffffff8088048f at trap_pfault+0xff > #10 0xffffffff8087fc38 at trap+0x348 > #11 0xffffffff808645d1 at calltrap+0x8 > > KDB: stack backtrace: > #0 0xffffffff805ca4b7 at kdb_backtrace+0x67 > #1 0xffffffff8058a3f6 at vpanic+0x186 > #2 0xffffffff8058a473 at panic+0x43 > #3 0xffffffff8056b564 at __mtx_assert+0xb4 > #4 0xffffffff80544780 at knlist_add+0x20 > #5 0xffffffff8041ead0 at netmap_kqfilter+0x110 > #6 0xffffffff804657f7 at devfs_kqfilter_f+0x77 > #7 0xffffffff80542a0b at kqueue_register+0x78b > #8 0xffffffff80543432 at kqueue_kevent+0x92 > #9 0xffffffff80543336 at kern_kevent_fp+0x96 > #10 0xffffffff8054324f at kern_kevent+0x9f > #11 0xffffffff80543058 at sys_kevent+0x138 > #12 0xffffffff80880dda at amd64_syscall+0x57a > #13 0xffffffff808648bb at Xfast_syscall+0xfb > > #0 doadump (textdump=) at pcpu.h:222 > #1 0xffffffff80589e70 in kern_reboot (howto=260) at > /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_shutdown.c:366 > #2 0xffffffff8058a430 in vpanic (fmt=, ap= optimized out>) > at > /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_shutdown.c:759 > #3 0xffffffff8058a473 in panic (fmt=) at > /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_shutdown.c:690 > #4 0xffffffff8056b564 in __mtx_assert (c=0x0, what=0, file=0x0, line=0) > at /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_mutex.c:1000 > #5 0xffffffff80544780 in knlist_add (knl=0xfffffe000a055450, > kn=0xfffff8026d097e80, islocked=1) > at > /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_event.c:2089 > #6 0xffffffff8041ead0 in netmap_kqfilter (dev=, > kn=0xfffff8026d097e80) > at > /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_freebsd.c:1354 > #7 0xffffffff804657f7 in devfs_kqfilter_f (fp=0xfffff8001faf8780, > kn=0xfffff8026d097e80) > at > /usr/local/share/deploy-tools/RELENG_11/src/sys/fs/devfs/devfs_vnops.c:837 > #8 0xffffffff80542a0b in kqueue_register (kq=0xfffff8001a65c000, > kev=0xfffffe045b4dc650, td=0xfffff8014ca71000, waitok=) > at > /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_event.c:1334 > #9 0xffffffff80543432 in kqueue_kevent (kq=0xfffff8001a65c000, > td=0xfffff8014ca71000, nchanges=4, nevents=, > k_ops=0xfffffe045b4dc8a0, > timeout=) at > /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_event.c:1019 > #10 0xffffffff80543336 in kern_kevent_fp (td=0xfffff8014ca71000, > fp=, nchanges=4, nevents=, > k_ops=, timeout=) at > /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_event.c:1050 > #11 0xffffffff8054324f in kern_kevent (td=0xfffff8014ca71000, fd=7, > nchanges=4, nevents=0, k_ops=0xfffffe045b4dc8a0, timeout=0x0) > at /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_event.c:993 > #12 0xffffffff80543058 in sys_kevent (td=0xfffff8014ca71000, > uap=0xfffffe045b4dca30) at > /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_event.c:925 > #13 0xffffffff80880dda in amd64_syscall (td=0xfffff8014ca71000, > traced=0) at subr_syscall.c:135 > #14 0xffffffff808648bb in Xfast_syscall () at > /usr/local/share/deploy-tools/RELENG_11/src/sys/amd64/amd64/exception.S:396 > #15 0x000000080122813a in ?? () … > Does anybody have a quick idea if it's easily fixable, or a complicated > issue, possibly caused due to MFC boch? Similar panic happens with stable/11 native netmap code, see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219846 Hope this can be fixed before 11.1-RELEASE? Thanks, -harry From owner-freebsd-net@freebsd.org Wed Jun 7 19:59:08 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ECEB4D7C5BC for ; Wed, 7 Jun 2017 19:59:08 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AEE5B81C10 for ; Wed, 7 Jun 2017 19:59:08 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-ot0-x231.google.com with SMTP id t31so12800906ota.1 for ; Wed, 07 Jun 2017 12:59:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BIK+ZAnx+9CUYDGCHIGXJEtqsULOOaEMUwkXHMzsTeU=; b=VxY/mquFVkx+5xvSOGqdBNjuvhYqcoUybBRzZGxr0R9h0d7F9K0KCE9I+LWTuhwUzb GmgRKJUbwmKVxtsPHV2ArDpk12ios+kvBD5uKE2gXcZfHVMAJzynfTv3EAgjUWhAN3V3 nB7j8IiLW6OXEKwowCWM3AwBPBNrAQKC8/HMlTG/Z2KFQn6P51RISPQYdFZNWltTABkz oIWPeQ4rbCVtK979Kdh080oTx1Sa2BAsL0zyIK1teFxKy1ua9L6VWaXvTOQVofxnyD5w 3zhrfeUCj4mCUPhMXYHMmkMk6yZnOoL8FMmdRxnOMtb9gJPQ135hmJPLfotdbl3NZMA1 OrnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BIK+ZAnx+9CUYDGCHIGXJEtqsULOOaEMUwkXHMzsTeU=; b=bbKubiuWOwIXgUuzOb1PZZSUY4wqHzMNmbYR5L3pUk9mv7bjVMJB4x/L/rlrRMaKBN RMWeOMgEpFfy8jlPppfhF/FDGNFvVTBjHBL6CaGNNp+WpaR6vEVDtyfm29ocVY8IwG0S ORdL/E+UjLyl4tulch9dbAyosxjptuDp/xbfhvT5Hx7qfsV76nbtxU7ZWB6IdOh6rEaS YEscUc14IbU1EwOkD5mocjEw3TL7VAO8yH03yrHIXB+W6c0GvocmLhg+wuZuUc/kjTFV 9H8hNzzwuhT4DYjhK++RvdzGvOSf54+LPCiAzVfe51Rv8tS/sHbetwm+OUfMsqJZa8ce PnWw== X-Gm-Message-State: AODbwcBuIwPGHXEyoFbYrZtX1oIVNhvko2Pe4CXPBqwrUKYpTtoSPqWS +tdYrUwdJErWxtFtXaugiyYHDxs22RzS X-Received: by 10.157.60.141 with SMTP id z13mr16159563otc.47.1496865547881; Wed, 07 Jun 2017 12:59:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.17.49 with HTTP; Wed, 7 Jun 2017 12:59:07 -0700 (PDT) In-Reply-To: <59382991.8000502@omnilan.de> References: <59380BC1.7090300@omnilan.de> <59382991.8000502@omnilan.de> From: Vincenzo Maffione Date: Wed, 7 Jun 2017 21:59:07 +0200 Message-ID: Subject: Re: panic after LOR, 2nd netmap_mem2.c, 1st vm_fault.c To: Harry Schmalzbauer Cc: FreeBSD Net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 19:59:09 -0000 Hi, I see this happening all the time, it's a locking problem. It does not cause a panic, usually. Can you please open an issue on the github tracker ( https://github.com/luigirizzo/netmap)? Thanks, Vincenzo 2017-06-07 18:28 GMT+02:00 Harry Schmalzbauer : > Bez=C3=BCglich Harry Schmalzbauer's Nachricht vom 07.06.2017 16:20 (loca= ltime): > > lock order reversal: (sleepable after non-sleepable) > > 1st 0xfffff8007519a960 vm object (vm object) @ > > /usr/local/share/deploy-tools/RELENG_11/src/sys/vm/vm_fault.c:572 > > 2nd 0xfffff8003299b000 (d)->nm_mtx ((d)->nm_mtx) @ > > /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/ > netmap_mem2.c:577 > > stack backtrace: > > #0 0xffffffff805e7900 at witness_debugger+0x70 > > #1 0xffffffff805e77f3 at witness_checkorder+0xe23 > > #2 0xffffffff80591f4e at _sx_xlock+0x5e > > #3 0xffffffff8042275a at netmap_mem2_ofstophys+0x2a > > #4 0xffffffff8041f3ab at netmap_dev_pager_fault+0x3b > > #5 0xffffffff8082d834 at dev_pager_getpages+0x74 > > #6 0xffffffff80856d2a at vm_pager_get_pages+0x4a > > #7 0xffffffff8083aa92 at vm_fault_hold+0xa52 > > #8 0xffffffff80839ff5 at vm_fault+0x75 > > #9 0xffffffff8088048f at trap_pfault+0xff > > #10 0xffffffff8087fc38 at trap+0x348 > > #11 0xffffffff808645d1 at calltrap+0x8 > > > > KDB: stack backtrace: > > #0 0xffffffff805ca4b7 at kdb_backtrace+0x67 > > #1 0xffffffff8058a3f6 at vpanic+0x186 > > #2 0xffffffff8058a473 at panic+0x43 > > #3 0xffffffff8056b564 at __mtx_assert+0xb4 > > #4 0xffffffff80544780 at knlist_add+0x20 > > #5 0xffffffff8041ead0 at netmap_kqfilter+0x110 > > #6 0xffffffff804657f7 at devfs_kqfilter_f+0x77 > > #7 0xffffffff80542a0b at kqueue_register+0x78b > > #8 0xffffffff80543432 at kqueue_kevent+0x92 > > #9 0xffffffff80543336 at kern_kevent_fp+0x96 > > #10 0xffffffff8054324f at kern_kevent+0x9f > > #11 0xffffffff80543058 at sys_kevent+0x138 > > #12 0xffffffff80880dda at amd64_syscall+0x57a > > #13 0xffffffff808648bb at Xfast_syscall+0xfb > > > > #0 doadump (textdump=3D) at pcpu.h:222 > > #1 0xffffffff80589e70 in kern_reboot (howto=3D260) at > > /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_shutdown.c:36= 6 > > #2 0xffffffff8058a430 in vpanic (fmt=3D, ap=3D > optimized out>) > > at > > /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_shutdown.c:75= 9 > > #3 0xffffffff8058a473 in panic (fmt=3D) at > > /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_shutdown.c:69= 0 > > #4 0xffffffff8056b564 in __mtx_assert (c=3D0x0, what=3D0, file=3D0x0, = line=3D0) > > at /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_ > mutex.c:1000 > > #5 0xffffffff80544780 in knlist_add (knl=3D0xfffffe000a055450, > > kn=3D0xfffff8026d097e80, islocked=3D1) > > at > > /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_event.c:2089 > > #6 0xffffffff8041ead0 in netmap_kqfilter (dev=3D, > > kn=3D0xfffff8026d097e80) > > at > > /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/ > netmap_freebsd.c:1354 > > #7 0xffffffff804657f7 in devfs_kqfilter_f (fp=3D0xfffff8001faf8780, > > kn=3D0xfffff8026d097e80) > > at > > /usr/local/share/deploy-tools/RELENG_11/src/sys/fs/devfs/ > devfs_vnops.c:837 > > #8 0xffffffff80542a0b in kqueue_register (kq=3D0xfffff8001a65c000, > > kev=3D0xfffffe045b4dc650, td=3D0xfffff8014ca71000, waitok=3D out>) > > at > > /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_event.c:1334 > > #9 0xffffffff80543432 in kqueue_kevent (kq=3D0xfffff8001a65c000, > > td=3D0xfffff8014ca71000, nchanges=3D4, nevents=3D, > > k_ops=3D0xfffffe045b4dc8a0, > > timeout=3D) at > > /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_event.c:1019 > > #10 0xffffffff80543336 in kern_kevent_fp (td=3D0xfffff8014ca71000, > > fp=3D, nchanges=3D4, nevents=3D, > > k_ops=3D, timeout=3D) at > > /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_event.c:1050 > > #11 0xffffffff8054324f in kern_kevent (td=3D0xfffff8014ca71000, fd=3D7, > > nchanges=3D4, nevents=3D0, k_ops=3D0xfffffe045b4dc8a0, timeout=3D0x0) > > at /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_ > event.c:993 > > #12 0xffffffff80543058 in sys_kevent (td=3D0xfffff8014ca71000, > > uap=3D0xfffffe045b4dca30) at > > /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_event.c:925 > > #13 0xffffffff80880dda in amd64_syscall (td=3D0xfffff8014ca71000, > > traced=3D0) at subr_syscall.c:135 > > #14 0xffffffff808648bb in Xfast_syscall () at > > /usr/local/share/deploy-tools/RELENG_11/src/sys/amd64/amd64/ > exception.S:396 > > #15 0x000000080122813a in ?? () > =E2=80=A6 > > Does anybody have a quick idea if it's easily fixable, or a complicated > > issue, possibly caused due to MFC boch? > > Similar panic happens with stable/11 native netmap code, see > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219846 > > Hope this can be fixed before 11.1-RELEASE? > > Thanks, > > -harry > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > --=20 Vincenzo Maffione From owner-freebsd-net@freebsd.org Wed Jun 7 21:04:17 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D1835D7D394 for ; Wed, 7 Jun 2017 21:04:17 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9251783762 for ; Wed, 7 Jun 2017 21:04:17 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-oi0-x232.google.com with SMTP id p7so10917423oif.2 for ; Wed, 07 Jun 2017 14:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7YAFoI9F4+/wbCSNYRhY+rE/eQ9JtZfmobjxVMTAji4=; b=gyjFGiiu8yYRXE6k7bc2AMTqMQqgnImLhuqizIfYa1jSjGKGWxCtH4PGV7n8Qh0CaG HFVcQsdsIKkup2w1danjDdpexOAp756TyxrvWPK0n0lRKcDD7bzIUyVjw9g+Q9+xNhj2 SmaItTxJ3Szdx/p11IYtLcote0D3SWpFuiv3jpspgQsN8pYUdziC9WB2lleHON+oYgX7 eqhIBgsdD7SiatcVkkQ8mwuhI2qzS2BZuzsJ+qRV662cGYVaHdJeqO9qPdBojAVIeI13 6vNAR/ZHPNu7vTH5NzT2yFhLDlKFC6tXCUdQWGjo0paL/GReHwkRpkQglYIcCnapS78N v8dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7YAFoI9F4+/wbCSNYRhY+rE/eQ9JtZfmobjxVMTAji4=; b=WmqDuUz0N3KuJWiOspAOpH0nz+M1XVCPPvPGOKSwQGSGDH5i6OXDjEc3mNGh0WbLHi faRIgkRx/QC2ZwYAktVGrXnZfwJ6KmC9cKs5xTsO+Flgx1Ui8sgebsijBehTElQ7q6fa SG0YhYfR+oq0ANN0NaCGOshp72yd5vkiQtrTP7j3pnPnTudxXN5BlUKxjJa557Oilf+u BFL+DxOc8TiIAmsfiquXpzdBtLI2rQuo7tY4qmHsnvWQyvfuCjXEjcWsjBOpJ0SBKn9P pSCmFos/XqCRtRcBrXsVB/3xKItxFV6UJwjN4NSHZLouM8sN4/gz/vKj9mDxKKbIm5wL 5rpQ== X-Gm-Message-State: AODbwcB0sirETkPO8JnigF+f/KqUa+6143hRGn/hsQU7moW037N1IQkV 4EFKNb+2pPb7aurfMe3l1AV66k1wMA== X-Received: by 10.202.50.213 with SMTP id y204mr18852709oiy.164.1496869456862; Wed, 07 Jun 2017 14:04:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.17.49 with HTTP; Wed, 7 Jun 2017 14:04:16 -0700 (PDT) In-Reply-To: <59367CF5.9080101@omnilan.de> References: <5926FFDB.7040900@omnilan.de> <592F20A0.4020702@omnilan.de> <592FC60A.1030308@omnilan.de> <5935A20A.6040000@omnilan.de> <59367CF5.9080101@omnilan.de> From: Vincenzo Maffione Date: Wed, 7 Jun 2017 23:04:16 +0200 Message-ID: Subject: Re: ovs-netmap forgotten? To: Harry Schmalzbauer Cc: freebsd-net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 21:04:17 -0000 You can play with NIC interrupt coalescing settings to keep them under control (I don't know how in FreeBSD, but in Linux you would do that with e.g. "ethtool -C rx-usecs 100"). As written in the last line of netmap(4), you must disable all the offloadings when playing with netmap physical ports. By the way, there is a person working on adding some offloading support to netmap, but this is still in progress and it is not even in the netmap github yet. Cheers, Vincenzo 2017-06-06 11:59 GMT+02:00 Harry Schmalzbauer : > Bez=C3=BCglich Harry Schmalzbauer's Nachricht vom 05.06.2017 20:25 (loca= ltime): > > Bez=C3=BCglich Vincenzo Maffione's Nachricht vom 05.06.2017 16:06 (loca= ltime): > > > =E2=80=A6 > > First quick test shows you're right and this tiny diff solves a decent > > share of my (ESXi-replacing) problems: > > > > --- src/sys/net/if_vlan.c.orig 2017-06-05 17:39:27.770574000 +0200 > > +++ src/sys/net/if_vlan.c 2017-06-05 17:39:21.550278000 +0200 > > @@ -1234,7 +1234,7 @@ > > if_inc_counter(ifv->ifv_ifp, IFCOUNTER_IPACKETS, 1); > > > > /* Pass it back through the parent's input routine. */ > > - (*ifp->if_input)(ifv->ifv_ifp, m); > > + (*ifv->ifv_ifp->if_input)(ifv->ifv_ifp, m); > > } > > > > static int > > > > Will do real-world tests tommorrow. > > To share my observations: > > Attaching if_vlan(4) to vale(4) works with the above modification, as > long as vlanhwtag is _not_ disabled, at least with igb(4) and (em4). > Having other offloadings enabled or disabled (regardless if it's on > parent or vlan-clone) doesn't matter, disabling vlanhwtag on the parent > leads to congested parent if there's mor etraffic than console... I > haven't done any tracking if it's caused by TCP windows scaling e.g. nor > tried to ask the code, because I do want vlanhwtagging enabled and > that's what works so far :-) > This is also true for if_vlan(4) interfaces which have if_lagg(0) as > parent, and also for both types of vale(4) attaching, hoststack-detached > (-a) or hoststack-attached (-h). > So far very nice :-) > > But there's a interrupt multiplication noticeable (at the host). > > My simple NFS-copying test causes ~10ki/s at one igb(4) queue when > invoked on the host, with mtu 1500. > Same invocation in the guest, with vlan-vale setup, causes 30ki/s > average (with high discrepancy, 20-40k). > > Might it be possible that if_vlan(4) influences interrupt moderation > capabilities? > > Vincenzo, thanks for your answers to my questions, which I read during > writing of this - stripping them here. > > -harry > --=20 Vincenzo Maffione From owner-freebsd-net@freebsd.org Thu Jun 8 03:38:23 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 76CD1BF2A58 for ; Thu, 8 Jun 2017 03:38:23 +0000 (UTC) (envelope-from jordancaraballo87@gmail.com) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E4137111D for ; Thu, 8 Jun 2017 03:38:23 +0000 (UTC) (envelope-from jordancaraballo87@gmail.com) Received: by mail-wm0-x22d.google.com with SMTP id d73so22472830wma.0 for ; Wed, 07 Jun 2017 20:38:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=YPXiQX1rzJw8I85xLiZd7EYI9DxG3v2TMLByPs+M0NU=; b=lCjkABXedvcXQJbAwBUA+puuwbghZ3XkOY4nN6P5eO0YvIjdi6tGM2JQ3nyRxmW90u Qv8Bu1Eqjz/QbiFTkdUbV5Msg21VfmIzDN9OFo5seK/YMFRi1coOFr8LJ9X9Qeh6RuI0 8jwM8jQ0iXOYgIXy0IunNdjJe3kcUx0SvYpFhPe/wudrqVQhlfE0yklxjn7Rsr5nL+N1 Bq1pkp7KqTZi7FRTnHsozAH26wNp2fqUUCM9hS6JLC5ICVO3qYFEoXueG71YslzdB3zL Qm/REtEkpVrL0KS0VVYIezuPicC2edejR2KQBxaTUUZ4lpR2gKmpgJzsSUMEwHDxtlFh MyFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=YPXiQX1rzJw8I85xLiZd7EYI9DxG3v2TMLByPs+M0NU=; b=VTuiYUDLQQOL8K+RmFKgyBxKQ3vPOK2nX8oMh1j3Tt9gnFhNIhXvTftzRkFsdSnd5W Gozb6yM5JhuuQ/J2g/T5duosoyYvQgOBrYkK+sY0H4blw7MXIkkmoJqh0JjpnqWa+eSO fphmaUGLGdwzpepJGrKLOppmZPH2KrgH/AbDl6l9bLWjRPqckIykanSiYRrN6eQG/ZlW zDqp93EgyB+m72+3lyv4+FpaG02Nnw99mIwFi9Ev1riBGVan1xrI2WnAdFkx18JnPpv1 U5O8QL1xlNyu3zTjJBRnT89853pb2MKuZc2cprSd84z/KDhdykrEfYDc+kUGYO/zt0ax JHKg== X-Gm-Message-State: AODbwcCxgxxAF1AGXSr5LPGQVbA1F+poZo9jmbgWlM+JtOmb6tKYBIZm bdlm98vFnKupTpazT3289/9PLweArvhI X-Received: by 10.80.191.76 with SMTP id g12mr13426667edk.12.1496893101466; Wed, 07 Jun 2017 20:38:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.215.83 with HTTP; Wed, 7 Jun 2017 20:38:21 -0700 (PDT) From: Jordan Caraballo Date: Wed, 7 Jun 2017 23:38:21 -0400 Message-ID: Subject: chelsio T-580_CR DPDK link down To: freebsd-net@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 03:38:23 -0000 Hi guys, I am currently trying to implement DPDK in a Dell PE R530 equipped with a Chelsio T-580-CR port in an 8x slot. So far, links to ports do not want to come up. Below are the commands of my exact approach. ############################### Installed dpdk from /usr/ports/net/dpdk in a FreeBSD 11-STABLE system. Unloaded every module related to dpdk and cxgbe. Then: # kldload if_cxgbe=E2=80=A8# dmesg | grep "t5nex" # pciconf -l | grep "t5nex" Note: The result given from this command is primarily t5nex0@pci0:129:0:4: # kldunload if_cxgbe Added to /boot/loader.conf below configurations and rebooted the system: # reserve 2 x 1G blocks of contiguous memory using contigmem driver=E2=80=A8hw.contigmem.num_buffers=3D2=E2=80=A8hw.contigmem.buffer_siz= e=3D1073741824=E2=80=A8# load contigmem module during boot process=E2=80=A8contigmem_load=3D"YES" Once the system is rebooted we proceed to attach the pic address to nic_uio module. # kenv hw.nic_uio.bdfs=3D"129:0:4"=E2=80=A8# kldload nic_uio.ko=E2=80=A8# p= ciconf -l=E2=80=A8The result of pciconf -l at the t5nex0 pci is nic_uio@pci0:129:0:4: Tried to run:=E2=80=A8# /usr/local/share/dpdk/x86_64-native-bsdapp-clang/app/testpmd -l 0-3 -n 4 -w 0000:129:00.4 -- -i But it prompts to the usage options. Then ran: # /usr/local/share/dpdk/x86_64-native-bsdapp-clang/app/testpmd -l 0-3 -n 4 -- -i And script runs but links are down. At interactive mode I use "set link-up port 0=E2=80=9D but it fails to brin= g any of the ports up. ################################### - Any advice or idea? - Am I missing something? - Is there any other better approach rather than dpdk to increase packets per second forwarding in a router? In case of needing additional log information do not hesitate to ask. Thanks in advance, Jordan From owner-freebsd-net@freebsd.org Thu Jun 8 14:46:54 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 33E9BC086B1 for ; Thu, 8 Jun 2017 14:46:54 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id 0BABF320 for ; Thu, 8 Jun 2017 14:46:54 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id E574567C74; Thu, 8 Jun 2017 14:46:53 +0000 (UTC) Date: Thu, 8 Jun 2017 14:46:53 +0000 To: freebsd-net@freebsd.org From: "mleone87_hotmail.com (Uccio Papa)" Reply-to: D9270+325+bbd470fd257eef1b@reviews.freebsd.org Subject: [Differential] D9270: Add support for user-supplied Host-Uniq tag and handle PADM messages in Netgraph PPPoE Message-ID: <2c9585f0b39c3db83d3f850b341c76b8@localhost.localdomain> X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: Thread-Topic: D9270: Add support for user-supplied Host-Uniq tag in Netgraph PPPoE X-Herald-Rules: <28>, <8> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: NTZkNjQzYWQxOGQ3MGJlZTIzOGZhZmQ4NGNmIFk5Y10= MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 14:46:54 -0000 bWxlb25lODdfaG90bWFpbC5jb20gYWRkZWQgYSBjb21tZW50LgoKCiAgSW4gaHR0cHM6Ly9yZXZp ZXdzLmZyZWVic2Qub3JnL0Q5MjcwIzIxMjU0NywgQGFsZSB3cm90ZToKICAKICA+IEFkZHJlc3Nl ZCBsYXRlc3QgY29tbWVudHMsIHVwZGF0ZWQgYWxzbyB0aGUgcHBwb2UgZGlzY29ubmVjdCBmdW5j dGlvbi4KICA+ICBQbGVhc2UgY2hlY2sgdGhlIGNvcnJlY3RuZXNzLCBhbmQgY29tbWl0IHRoZSBw YXRjaCBpZiB5b3UgYXJlIHNhdGlzZmllZC4KICAKICAKICBIb3cgdGhlIHRhZyBzaG91bGQgYmUg ZGVmaW5lZCBpbiBtcGQuY29uZiB0aGVuPwogIAogIHNldCBhdXRoIGhvc3QtdW5pcSAic3RyaW5n IiA/CiAgCiAgVGhhbmtzCgpSRVBPU0lUT1JZCiAgclMgRnJlZUJTRCBzcmMgcmVwb3NpdG9yeQoK UkVWSVNJT04gREVUQUlMCiAgaHR0cHM6Ly9yZXZpZXdzLmZyZWVic2Qub3JnL0Q5MjcwCgpFTUFJ TCBQUkVGRVJFTkNFUwogIGh0dHBzOi8vcmV2aWV3cy5mcmVlYnNkLm9yZy9zZXR0aW5ncy9wYW5l bC9lbWFpbHByZWZlcmVuY2VzLwoKVG86IGFsZSwgI21hbnBhZ2VzLCB3YmxvY2ssICNuZXR3b3Jr LCBqdWxpYW4sIG1hdiwgYWRyaWFuLCBnbGViaXVzCkNjOiBmcmFuY29fb3Buc2Vuc2Uub3JnLCBt bGVvbmU4N19ob3RtYWlsLmNvbSwgZ2xlYml1cywgd2Jsb2NrLCBtYXYsIHBvb2xyb29tX2dtYWls LmNvbSwgbWFuZHJlZSwgaW1wLCBmcmVlYnNkLW5ldC1saXN0Cg== From owner-freebsd-net@freebsd.org Thu Jun 8 15:30:06 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3AB7BC08D71 for ; Thu, 8 Jun 2017 15:30:06 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id 0DD091895 for ; Thu, 8 Jun 2017 15:30:06 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id D0F006D35C; Thu, 8 Jun 2017 15:30:05 +0000 (UTC) Date: Thu, 8 Jun 2017 15:30:05 +0000 To: freebsd-net@freebsd.org From: "ale (Alex Dupre)" Reply-to: D9270+325+bbd470fd257eef1b@reviews.freebsd.org Subject: [Differential] D9270: Add support for user-supplied Host-Uniq tag and handle PADM messages in Netgraph PPPoE Message-ID: X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: Thread-Topic: D9270: Add support for user-supplied Host-Uniq tag in Netgraph PPPoE X-Herald-Rules: <28>, <8> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: NTZkNjQzYWQxOGQ3MGJlZTIzOGZhZmQ4NGNmIFk5bX0= MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 15:30:06 -0000 YWxlIGFkZGVkIGEgY29tbWVudC4KCgogID4gSG93IHRoZSB0YWcgc2hvdWxkIGJlIGRlZmluZWQg aW4gbXBkLmNvbmYgdGhlbj8KICA+IAogID4gc2V0IGF1dGggaG9zdC11bmlxICJzdHJpbmciID8K ICAKICBObywgdG8ganVzdCBzZXQgdGhlIGhvc3QtdW5pcSBzdHJpbmcgeW91IHNob3VsZCB1c2U6 CiAgCiAgc2V0IHBwcG9lIHNlcnZpY2UgInN0cmluZ3wiCgpSRVBPU0lUT1JZCiAgclMgRnJlZUJT RCBzcmMgcmVwb3NpdG9yeQoKUkVWSVNJT04gREVUQUlMCiAgaHR0cHM6Ly9yZXZpZXdzLmZyZWVi c2Qub3JnL0Q5MjcwCgpFTUFJTCBQUkVGRVJFTkNFUwogIGh0dHBzOi8vcmV2aWV3cy5mcmVlYnNk Lm9yZy9zZXR0aW5ncy9wYW5lbC9lbWFpbHByZWZlcmVuY2VzLwoKVG86IGFsZSwgI21hbnBhZ2Vz LCB3YmxvY2ssICNuZXR3b3JrLCBqdWxpYW4sIG1hdiwgYWRyaWFuLCBnbGViaXVzCkNjOiBmcmFu Y29fb3Buc2Vuc2Uub3JnLCBtbGVvbmU4N19ob3RtYWlsLmNvbSwgZ2xlYml1cywgd2Jsb2NrLCBt YXYsIHBvb2xyb29tX2dtYWlsLmNvbSwgbWFuZHJlZSwgaW1wLCBmcmVlYnNkLW5ldC1saXN0Cg== From owner-freebsd-net@freebsd.org Fri Jun 9 09:57:27 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4F1C2BF0F55 for ; Fri, 9 Jun 2017 09:57:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 30D981277 for ; Fri, 9 Jun 2017 09:57:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v599vQwT065186 for ; Fri, 9 Jun 2017 09:57:27 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 219703] System freeze when creating bridge over vlan over lagg over ixgbe Date: Fri, 09 Jun 2017 09:57:27 +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: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: topical@gmx.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-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 MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 09:57:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219703 --- Comment #3 from topical --- It's a production system with a couple of VMs, so I'm a bit of reluctant fiddling with unstable code. I read that once I will have upgraded to non-RELEASE, there is no way back.= Is there any trick to avoid that? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Jun 9 16:50:04 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3C2ABF8CDC for ; Fri, 9 Jun 2017 16:50:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C1DE873F3C for ; Fri, 9 Jun 2017 16:50:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v59Go44f060845 for ; Fri, 9 Jun 2017 16:50:04 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 211219] NIC status does not pass into a state of "no carrier" after disconnecting the cable. Date: Fri, 09 Jun 2017 16:50:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.3-RELEASE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: franco@opnsense.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-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 MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 16:50:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211219 --- Comment #22 from Franco Fichtner --- Dear all, The code is still incorrect, could somebody please look at this? The "delay" in addressing this issue is extreme given that a patch exists s= ince February. If somebody would let me know which mistake I made I would like t= o be able to avoid it in the future. Thank you, Franco --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sat Jun 10 15:58:40 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A29D4BF04B6 for ; Sat, 10 Jun 2017 15:58:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8FB267D760 for ; Sat, 10 Jun 2017 15:58:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v5AFwdSk094235 for ; Sat, 10 Jun 2017 15:58:40 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 211219] NIC status does not pass into a state of "no carrier" after disconnecting the cable. Date: Sat, 10 Jun 2017 15:58:39 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.3-RELEASE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: eugen@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution cc 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 MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 15:58:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211219 Eugene Grosbein changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |--- CC| |eugen@freebsd.org Status|Closed |Open --- Comment #23 from Eugene Grosbein --- Apparently, closed by mistake: no track of fixing commit and there is a rep= ort the problem's still here. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sat Jun 10 16:44:00 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD9AABF1A73 for ; Sat, 10 Jun 2017 16:44:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BBDB07F380 for ; Sat, 10 Jun 2017 16:44:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v5AGi0bm017814 for ; Sat, 10 Jun 2017 16:44:00 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 211219] NIC status does not pass into a state of "no carrier" after disconnecting the cable. Date: Sat, 10 Jun 2017 16:44:00 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.3-RELEASE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: erj@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-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 MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 16:44:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211219 --- Comment #24 from Eric Joyner --- Since it appears Sean is dead/busy, I'll look at this. --=20 You are receiving this mail because: You are the assignee for the bug.=