[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191023100132.GD8732@netronome.com>
Date: Wed, 23 Oct 2019 12:01:32 +0200
From: Simon Horman <simon.horman@...ronome.com>
To: Matteo Croce <mcroce@...hat.com>
Cc: netdev@...r.kernel.org, Jay Vosburgh <j.vosburgh@...il.com>,
Veaceslav Falico <vfalico@...il.com>,
Andy Gospodarek <andy@...yhouse.net>,
"David S . Miller " <davem@...emloft.net>,
Stanislav Fomichev <sdf@...gle.com>,
Daniel Borkmann <daniel@...earbox.net>,
Song Liu <songliubraving@...com>,
Alexei Starovoitov <ast@...nel.org>,
Paul Blakey <paulb@...lanox.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 4/4] bonding: balance ICMP echoes in layer3+4
mode
On Mon, Oct 21, 2019 at 10:09:48PM +0200, Matteo Croce wrote:
> The bonding uses the L4 ports to balance flows between slaves.
> As the ICMP protocol has no ports, those packets are sent all to the
> same device:
>
> # tcpdump -qltnni veth0 ip |sed 's/^/0: /' &
> # tcpdump -qltnni veth1 ip |sed 's/^/1: /' &
> # ping -qc1 192.168.0.2
> 1: IP 192.168.0.1 > 192.168.0.2: ICMP echo request, id 315, seq 1, length 64
> 1: IP 192.168.0.2 > 192.168.0.1: ICMP echo reply, id 315, seq 1, length 64
> # ping -qc1 192.168.0.2
> 1: IP 192.168.0.1 > 192.168.0.2: ICMP echo request, id 316, seq 1, length 64
> 1: IP 192.168.0.2 > 192.168.0.1: ICMP echo reply, id 316, seq 1, length 64
> # ping -qc1 192.168.0.2
> 1: IP 192.168.0.1 > 192.168.0.2: ICMP echo request, id 317, seq 1, length 64
> 1: IP 192.168.0.2 > 192.168.0.1: ICMP echo reply, id 317, seq 1, length 64
>
> But some ICMP packets have an Identifier field which is
> used to match packets within sessions, let's use this value in the hash
> function to balance these packets between bond slaves:
>
> # ping -qc1 192.168.0.2
> 0: IP 192.168.0.1 > 192.168.0.2: ICMP echo request, id 303, seq 1, length 64
> 0: IP 192.168.0.2 > 192.168.0.1: ICMP echo reply, id 303, seq 1, length 64
> # ping -qc1 192.168.0.2
> 1: IP 192.168.0.1 > 192.168.0.2: ICMP echo request, id 304, seq 1, length 64
> 1: IP 192.168.0.2 > 192.168.0.1: ICMP echo reply, id 304, seq 1, length 64
>
> Signed-off-by: Matteo Croce <mcroce@...hat.com>
I see where this patch is going but it is unclear to me what problem it is
solving. I would expect ICMP traffic to be low volume and thus able to be
handled by a single lower-device of a bond.
...
Powered by blists - more mailing lists