From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CD637CA9EC3 for ; Tue, 29 Oct 2019 20:08:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A10152067D for ; Tue, 29 Oct 2019 20:08:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=cumulusnetworks.com header.i=@cumulusnetworks.com header.b="RUiChNT+" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727569AbfJ2UIH (ORCPT ); Tue, 29 Oct 2019 16:08:07 -0400 Received: from mail-lj1-f195.google.com ([209.85.208.195]:35456 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727182AbfJ2UIH (ORCPT ); Tue, 29 Oct 2019 16:08:07 -0400 Received: by mail-lj1-f195.google.com with SMTP id m7so64744lji.2 for ; Tue, 29 Oct 2019 13:08:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cumulusnetworks.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=fW2Zh/fTxEZOQPa2raWuuwC2pp8Sz2KHBFNnTB4eWEs=; b=RUiChNT+/TnFFn5bjZwy2byqh22AKTbCJCBObmS8MMm0mlDFMZ3+ZUQvfEUKFxPfHG gKxqOXG9HM6Q9ws432DlC69CJ1HXXWAvsTZqvIDSOMrVjajWeWOgimDKr+6kQy+WHMTC b29b5ymq9R3f4xru5r7JFju+iQs56sx4I/u3o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fW2Zh/fTxEZOQPa2raWuuwC2pp8Sz2KHBFNnTB4eWEs=; b=JBeaY6EJspOGWR3Gh1zmdZ3IRl/Aqd7K/gEKgc/bAEst7QGZ1hyQ6+lk4L1ULMkp1G Wge9V45PsXd0l+wRIMLWnESBOkD4De2zIG7sutX1l4Ka3/33wT/6VZKMFlr7oDt8ksDb 9JSfezlHp1EROyf1yZfbT75mGBk6T7wI6RFe/mVbTcvkXqCHtfyjjHAwsdrsEfDpDYSP yahTwPzmWdcY7Cn0PPFqh/ey28VmZ5Mghq/euh5gJ9T0HyXJBgHjMx6PizqRaF5AGMcj kU8UO9GhLXn2ZcJlQ3nPe7NhCxKFwxVrB9+CwoVUeVxVF9X/lfWkwZs6LiIc32W3T0B4 WoBQ== X-Gm-Message-State: APjAAAVXiyi8DKGuW1OaUmiMEsIx4Hq9lZwFC6RNvYoSOQE0JFMvS9ZZ /YM22biPgIHtguUZ1B5+298TWBDB0ac= X-Google-Smtp-Source: APXvYqzrxTfHZiXkL4r08L/mBr55DZk5LZ8cDufkeXKRww3LG076jKVtRPf00+Gs2EEPUjqjgwsFZQ== X-Received: by 2002:a2e:8204:: with SMTP id w4mr3977803ljg.212.1572379683232; Tue, 29 Oct 2019 13:08:03 -0700 (PDT) Received: from [192.168.0.107] (84-238-136-197.ip.btc-net.bg. [84.238.136.197]) by smtp.gmail.com with ESMTPSA id w20sm9606082lff.46.2019.10.29.13.07.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Oct 2019 13:08:00 -0700 (PDT) Subject: Re: [PATCH net-next v2 4/4] bonding: balance ICMP echoes in layer3+4 mode To: Matteo Croce Cc: netdev , Jay Vosburgh , Veaceslav Falico , Andy Gospodarek , "David S . Miller" , Stanislav Fomichev , Daniel Borkmann , Song Liu , Alexei Starovoitov , Paul Blakey , LKML References: <20191029135053.10055-1-mcroce@redhat.com> <20191029135053.10055-5-mcroce@redhat.com> <5be14e4e-807f-486d-d11a-3113901e72fe@cumulusnetworks.com> From: Nikolay Aleksandrov Message-ID: <568200b1-fa27-6cb2-7586-d79829b24e4c@cumulusnetworks.com> Date: Tue, 29 Oct 2019 22:07:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 29/10/2019 21:45, Matteo Croce wrote: > On Tue, Oct 29, 2019 at 7:41 PM Nikolay Aleksandrov > wrote: >> >> On 29/10/2019 20:35, Nikolay Aleksandrov wrote: >>> Hi Matteo, >>> Wouldn't it be more useful and simpler to use some field to choose the slave (override the hash >>> completely) in a deterministic way from user-space ? >>> For example the mark can be interpreted as a slave id in the bonding (should be >>> optional, to avoid breaking existing setups). ping already supports -m and >>> anything else can set it, this way it can be used to do monitoring for a specific >>> slave with any protocol and would be a much simpler change. >>> User-space can then implement any logic for the monitoring case and as a minor bonus >>> can monitor the slaves in parallel. And the opposite as well - if people don't want >>> these balanced for some reason, they wouldn't enable it. >>> >> >> Ooh I just noticed you'd like to balance replies as well. Nevermind >> > > Also, the bonding could be in a router in the middle so no way to read the mark. > Yeah, of course. I was just thinking from the host monitoring POV as I thought that was the initial intent (reading the last set's discussion). Anyway the patch looks good to me, Reviewed-by: Nikolay Aleksandrov