From owner-freebsd-bugs@freebsd.org Wed Jul 10 13:26:02 2019 Return-Path: Delivered-To: freebsd-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23CE015D7131 for ; Wed, 10 Jul 2019 13:26:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B196B8BA4E for ; Wed, 10 Jul 2019 13:26:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 6D26615D712F; Wed, 10 Jul 2019 13:26:01 +0000 (UTC) Delivered-To: bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3282D15D712E for ; Wed, 10 Jul 2019 13:26:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A25C08BA4A for ; Wed, 10 Jul 2019 13:26: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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id D7D6F4FBB for ; Wed, 10 Jul 2019 13:25:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x6ADPxEa028162 for ; Wed, 10 Jul 2019 13:25:59 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x6ADPxnH028160 for bugs@FreeBSD.org; Wed, 10 Jul 2019 13:25:59 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 239112] [LACP] Latency problem when reconfiguring LACP links Date: Wed, 10 Jul 2019 13:25:59 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: nicolas.masse@stormshield.eu X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: 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-bugs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 13:26:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D239112 Bug ID: 239112 Summary: [LACP] Latency problem when reconfiguring LACP links Product: Base System Version: 11.2-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: nicolas.masse@stormshield.eu Created attachment 205657 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D205657&action= =3Dedit proposed fix Recently, me and my company came across a problem with lacp: We observed that since we migrate from FreeBSD10.3 to FreeBSD11.2, sometimes the lacp links takes several seconds (+/- 6 seconds) to get configured properly. This was observed when re-creating the lacp links from scratch using the following commands: ifconfig lagg0 inet 192.168.29.131/24 delete ifconfig igb1 down ifconfig lagg0 -laggport igb1 ifconfig lagg0 ether 00:00:00:00:00:00 ifconfig igb1 mtu 1500 ifconfig igb1 media autoselect ifconfig lagg0 laggproto lacp ifconfig lagg0 laggport igb1 ifconfig lagg0 mtu 1500 ifconfig lagg0 ether 0:d:b4:e:ba:e1 ifconfig lagg0 inet 192.168.29.131/24 ifconfig igb1 up ifconfig lagg0 up After some research, we found that the problem comes from the commit https://svnweb.freebsd.org/base?view=3Drevision&revision=3D332834. >From what I understand, here is what happens: - lacp_select is called. In the case we don't see our peer yet, it does nothing. - since it does nothing, the flag LACP_SELECTED isn't set. As a consequence, the timer LACP_TIMER_WAIT_WHILE isn't armed. - Since this timer isn't armed, we have to wait for the timer LACP_TIMER_CURRENT_WHILE to be triggered instead, adding an extra latency we didn't observe before (up to 6 seconds). This extra latency is a problem for us since we have a lot of automated regression tests, and it makes them taking twice as much time to run than before because we have to wait to be sure that the link is created properly. So I tried to see if I can solve this, and came across the following fix (s= ee the attached patch): - In lacp_select, in the case we haven't seen our peer yet, I still create = the aggregator if he doesn't exists yet and set LACP_SELECTED, but I dont fill = the aggregator id. - In the next call to lacp_select, i test if the aggregator id id filled by checking the LACP_STATE_AGGREGATION flag. In the case this isn't set the aggregator id is filled and the flag is set. Since LACP_SELECTED is set anew in the first call to lacp_select, the LACP_TIMER_WAIT_WHILE is armed and triggered as it was before the revision 332834. Early testing of this patch in our environnement show us that with this the extra latency is gone and things seems to work properly. --=20 You are receiving this mail because: You are the assignee for the bug.=