From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: 802.3ad bonding brain damaged? Date: Mon, 08 Aug 2011 17:59:28 +0200 Message-ID: <1312819168.2531.3.camel@edumazet-laptop> References: <4E3EECF6.90409@cfl.rr.com> <1312790234.7020.26.camel@arkology.n2.diac24.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Phillip Susi , netdev@vger.kernel.org To: David Lamparter Return-path: Received: from mail-wy0-f174.google.com ([74.125.82.174]:64664 "EHLO mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752338Ab1HHP7d (ORCPT ); Mon, 8 Aug 2011 11:59:33 -0400 Received: by wyg24 with SMTP id 24so135853wyg.19 for ; Mon, 08 Aug 2011 08:59:32 -0700 (PDT) In-Reply-To: <1312790234.7020.26.camel@arkology.n2.diac24.net> Sender: netdev-owner@vger.kernel.org List-ID: Le lundi 08 ao=C3=BBt 2011 =C3=A0 09:57 +0200, David Lamparter a =C3=A9= crit : > Am Sonntag, den 07.08.2011, 15:52 -0400 schrieb Phillip Susi: > > - From Documentation/networking/bonding.txt: > >=20 > > Additionally, the linux bonding 802.3ad implementation > > distributes traffic by peer (using an XOR of MAC addresses), > >=20 > > This is counter to the entire point of 802.3ad. Distributing traffi= c by > > hash of the destination address is poor mans load balancing for > > systems not supporting 802.3ad.=20 >=20 > No, it isn't. 802.3ad/.1AX explicitly requires that no packet > re-ordering may ever occur, which can only be guaranteed by enqueuein= g > packets for one host on one TX interface. This behaviour is mandated = by > 802.1AX-2008 page 15 which reads: >=20 > This standard does not mandate any particular distribution > algorithm(s); however, any distribution algorithm shall ensure that= , > when frames are received by a Frame Collector as specified in 5.2.3= , > the algorithm shall not cause > a) Misordering of frames that are part of any given conversation, o= r > b) Duplication of frames. > | The above requirement to maintain frame ordering is met by ensuring > | that all frames that compose a given conversation are transmitted o= n a > | single link in the order that they are generated by the MAC Client; > hence, this requirement does not involve the addition (or > modification) of any information to the MAC frame, nor any bufferin= g > or processing on the part of the corresponding Frame Collector in > order to reorder frames. This approach to the operation of the > distribution function permits a wide variety of distribution and lo= ad > balancing algorithms to be used, while also ensuring interoperabili= ty > between devices that adopt differing algorithms. >=20 It all depends on the definition of 'conversation' Phillip assumed two (or more) TCP flows from machine A to machine B could use two different links, while you assert they MUST use a single link.