From owner-freebsd-net@FreeBSD.ORG Sun Mar 29 10:36:37 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE7BCCDB for ; Sun, 29 Mar 2015 10:36:37 +0000 (UTC) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::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 70B3AE76 for ; Sun, 29 Mar 2015 10:36:37 +0000 (UTC) Received: by qcay5 with SMTP id y5so49733693qca.1 for ; Sun, 29 Mar 2015 03:36:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=fyW/olx1kJhNeZoyhYhdmASXlsDCNVn3ZjOguQDEDGs=; b=Zu61Hzn2gwZ4luPFsuOxjIRB9PdhF9o/piGIMay5sZ5g+mD7S0d4c0nfvehTVyp/uv Wql9KGG60bCyA6ZyC7jEK9Wu1yuba4oUVP2IllOL5GH1kYR8BdT8C2mNQjMExhdbT8sk fKUw0bCj6mIOx6my6S7r5h/xahRGtFwabWRsRycThto0qE3vh5SuXWDfbl/HjanOvmeI 2krZvsM43HlZ5/zlM60+TDIeZ2D/2utlib2N1qzeQFxBV8ua2vTe/F5wLBaQtXDP7nvO LM0I9zlDJPS728P+l0FtUV5CC8se8vWchQHEF2y3ZgmeIf+n1SIt5IkPdyYy6VjZSqLq 1hOA== MIME-Version: 1.0 X-Received: by 10.229.96.194 with SMTP id i2mr36059167qcn.1.1427625396513; Sun, 29 Mar 2015 03:36:36 -0700 (PDT) Received: by 10.229.220.129 with HTTP; Sun, 29 Mar 2015 03:36:36 -0700 (PDT) In-Reply-To: <20150319175145.GH53237@strugglingcoder.info> References: <5506A5BB.5060204@selasky.org> <20150319175145.GH53237@strugglingcoder.info> Date: Sun, 29 Mar 2015 13:36:36 +0300 Message-ID: Subject: Re: Unbalanced LACP link From: Vitalii Duk To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 29 Mar 2015 10:36:37 -0000 It worked fine, but today I've got one more error: Mar 29 01:03:08 router kernel: igb1: Interface stopped DISTRIBUTING, possible flapping Mar 29 01:08:02 router kernel: igb2: Interface stopped DISTRIBUTING, possible flapping Mar 29 01:08:02 router kernel: igb3: Interface stopped DISTRIBUTING, possible flapping Mar 29 01:11:01 router kernel: igb1: Interface stopped DISTRIBUTING, possible flapping Mar 29 01:11:01 router kernel: igb0: Interface stopped DISTRIBUTING, possible flapping Mar 29 01:13:11 router kernel: igb0: Interface stopped DISTRIBUTING, possible flapping Mar 29 01:13:16 router kernel: igb1: Interface stopped DISTRIBUTING, possible flapping Mar 29 01:13:42 router kernel: igb2: Interface stopped DISTRIBUTING, possible flapping Mar 29 01:13:46 router kernel: igb3: Interface stopped DISTRIBUTING, possible flapping On 19 March 2015 at 19:51, hiren panchasara wrote: > On 03/17/15 at 12:34P, Adrian Chadd wrote: > > On 17 March 2015 at 11:33, Jason Wolfe wrote: > > > On Mon, Mar 16, 2015 at 2:43 AM, Hans Petter Selasky > wrote: > > >> On 03/16/15 10:37, Vitalii Duk wrote: > > >>> > > >>> I've changed use_flowid to 0 and it helped! But isn't it setting > > >>> significant? In a description it says "Shift flowid bits to prevent > > >>> multiqueue collisions". > > >> > > >> > > >> Hi, > > >> > > >> Maybe your ethernet hardware is not properly setting the m_flowid ... > > >> > > >> --HPS > > >> > > > > > > Flip use_flowid back to 1 and try setting > > > net.link.lagg.default_flowid_shift / net.link.lagg.X.flowid_shift to 0 > > > as Hiren suggested. r260179 added this shift, which has caused us > > > balancing issues with the i350/igb. > > > > > > https://svnweb.freebsd.org/base?view=revision&revision=260179 > > > > > > Based on Adrian's comment about igb/ixgbe not setting the 'full > > > flowid' under normal conditions, does that mean this shift should be 0 > > > by default to ensure we don't break balancing for devices that only > > > set the CPU/MSIX queue? > > > > Or we can just see if there's anything wrong with putting the full 32 > > bit RSS flowid in received packets that have them. > > It'd be nice to have but for now I am proposing following to fix a known > broken case because of an optimization: > https://reviews.freebsd.org/D2098 > > Cheers, > Hiren >