From owner-freebsd-net@freebsd.org Sun Nov 8 21:25:32 2015 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 E836FA291F4 for ; Sun, 8 Nov 2015 21:25:31 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::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 7BB1F1ECE for ; Sun, 8 Nov 2015 21:25:31 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by wikq8 with SMTP id q8so57580267wik.1 for ; Sun, 08 Nov 2015 13:25:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay_co_uk.20150623.gappssmtp.com; s=20150623; h=to:references:subject:from:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=46ykJNbOMcUlyUDPfmppnB/nO6D098pP7dXrR4L5SuM=; b=pUHND9ck/Jyfyg00oxPL1FZxsA+OB9VF9DS/HyGbPzKrF7mvwS3+wXIlkqNC62Frs0 NkXyIAPvXdkw0nHPWiUC/by7JSTzQSupkUD8yXkwNMh8+lPMEKa/y7XT8aWuQD/yEo0u NKdZyzuWikdsPndnehA18BvlhMt6wjvi1MIPZ+mWCnHcboBFQWuzauqCzDhL49ZgJJ+G qBX+5GGEfpvwpbQlFZCOjw93XetmKXzlqGiZwHLc1xbr/3Kj1PwAAGWn0qQVWCMQ6H+H P8QudKebA1sYawqCGYc/K0J5me/B1s3RlQMW4MiplA6xb+vjdS/zuKvqn+dSLiaAIyII Az4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:references:subject:from:message-id:date :user-agent:mime-version:content-type:content-transfer-encoding; bh=46ykJNbOMcUlyUDPfmppnB/nO6D098pP7dXrR4L5SuM=; b=jUWDV6xsXEbOAV11GA85k4XUq4XMbpO3y0FCwqPWv5NzE9q8e1Ya03/HShVWtA1Kat N77f395ySpYWsUOVtq7QOiyhIrXjrXERw3uFnQZ3jnqZZkY0iOnx8o5eHd4JTnUDftpm eStaB8jXDb1y37cVvWR6Vmb+om3ZCZXmONkwz+1JwwPa8TiU2+9uAx9NxmDIkHq4cH4I YXtzF6HUpr9iZ4jq9tksRTB/12jMaCdU9+hFfu3a1lUP2vkfclTgio72PLx0F40kikjJ /NmzgZmaPGhieMHWHCmU7JsLqT+lFyXwVXW+b1UrGh8XVkllhIo1OT0xNN25qQpxjIYh wxug== X-Gm-Message-State: ALoCoQltpXXC7nePG5vBwabL/BMOmfnlz+kLDj1xhfYB7GgCB6eLAXCO8SA5LfUa/sqhOLvDka3S X-Received: by 10.194.86.161 with SMTP id q1mr31553615wjz.88.1447017930016; Sun, 08 Nov 2015 13:25:30 -0800 (PST) Received: from [10.10.1.58] (liv3d.labs.multiplay.co.uk. [82.69.141.171]) by smtp.gmail.com with ESMTPSA id r12sm10647506wmd.17.2015.11.08.13.25.28 for (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 Nov 2015 13:25:29 -0800 (PST) To: freebsd-net@freebsd.org References: Subject: [PATCH] if_lagg driver enhancements. From: Steven Hartland Message-ID: <563FBDCF.1050509@multiplay.co.uk> Date: Sun, 8 Nov 2015 21:25:35 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 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, 08 Nov 2015 21:25:32 -0000 > IMHO, the patch introduces a layering violation, which is bad. This would > lead to problems in future. From a quick look I don't see any right now, > and patch is compatible with carp(4) just accidentially :) > > I would suggest the following approach: > > 1) Network protocols should register theirselves on the ifnet_link_event > EVENTHANDLER(9). > 2) The inet4 should send gratutious ARP on this event. > 3) The inet6 should send NA. > > As you see the patch would be entirely not about lagg(4) :) > > We've got some minor obstacles on the suggested way: > > - The if_link_state_change() function suppresses any processing if the link > hasn't changed, for example UP -> UP event. > > We can overcome this by adding a new pseudo state LINK_STATE_UPAGAIN (or > LINK_STATE_UPCHANGED or LINK_STATE_UPANOTHER or any better name you can > imagine). This pseudo state can't be stored in the ifp->if_link_state, but > it can be used to keep the state LINK_STATE_UP, but force triggering link > state hooks. > > I think this approach is more clean and error prone. It can lead only to > extraneous gratutious ARP sent in some cases, which is not critical. Hi Gleb I know this is an old one, but I've picked it up as I'm going to need it fixed for a project that goes live before Christmas. TBH I'm quite surprised that this is still an issue, as it makes failover mode pretty useless, in its current form. As I understand you're proposal, it was to have each protocol e.g. ipv4, ipv6 register an ifnet_link_event handler. This when combined with lagg_linkstate using LINK_STATE_UPAGAIN (or some other name for it) to ensure that ifnet_link_event is fired so that even when lagg failover mode transitions from backup link to master link live, hence laggX going from UP(backup) -> UP(master) a broadcast is still triggered. Would this be a correct summary of your proposal? One thing that springs to mind is to avoid introducing a new if_link_state value and instead have lagg invoke the event directly in this special case. This is it would avoid the unnecessary do_link_state_change call and all the processing associated with that which is unneeded and could have unintended side effects. Alternatively still have the additional link_state but have if_link_state_change process it directly without enqueueing the task for do_link_state_change, which keeps the layer separation more strictly. What do you think? Regards Steve