Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 31 Aug 2013 19:15:33 -0700 (PDT)
From:      Barney Cordoba <barney_cordoba@yahoo.com>
To:        "T.C. Gubatayao" <tgubatayao@barracuda.com>, Luigi Rizzo <rizzo@iet.unipi.it>, Alan Somers <asomers@freebsd.org>
Cc:        Jack F Vogel <jfv@freebsd.org>, "Justin T. Gibbs" <gibbs@freebsd.org>, Andre Oppermann <andre@freebsd.org>, "net@freebsd.org" <net@freebsd.org>
Subject:   Re: Flow ID, LACP, and igb
Message-ID:  <1378001733.36695.YahooMailNeo@web121606.mail.ne1.yahoo.com>
In-Reply-To: <BCC2C62D4FE171479E2F1C2593FE508B0BE2440B@BN-SCL-MBX03.Cudanet.local>
References:  <D01A0CB2-B1E3-4F4B-97FA-4C821C0E3FD2@FreeBSD.org> <521BBD21.4070304@freebsd.org> <CAOtMX2jvKGY==t9i-a_8RtMAPH2p1VDj950nMHHouryoz3nbsA@mail.gmail.com> <521EE8DA.3060107@freebsd.org> <BCC2C62D4FE171479E2F1C2593FE508B0BE24383@BN-SCL-MBX03.Cudanet.local> <CAOtMX2h5SGh5eYV50y%2BQB_s367V9iattGU862wwXcONDV%2BTG8g@mail.gmail.com> <CA%2BhQ2%2BhgTaK1ZCOLGVFjSPY8nyNPHK4waSecyRQxR1gQcyjztg@mail.gmail.com>, <1377952913.44129.YahooMailNeo@web121605.mail.ne1.yahoo.com> <BCC2C62D4FE171479E2F1C2593FE508B0BE2440B@BN-SCL-MBX03.Cudanet.local>

next in thread | previous in thread | raw e-mail | index | archive | help
No, no. The entire point of the hash is to separate the "connections". But =
when testing you should=0Ause realistic assumptions. You're not splitting p=
ackets, so the big packets will mess up your distribution=0Aif you don't ge=
t it right.=A0=0A=0AOf course there's nothing really wrong with OOO packets=
. We had this discussion before; lots of people=0Ahave round robin dual hom=
ing without any ill effects. It's just not an issue.=0A=0A=0ABC=0A=0A______=
__________________________=0A From: T.C. Gubatayao <tgubatayao@barracuda.co=
m>=0ATo: Barney Cordoba <barney_cordoba@yahoo.com>; Luigi Rizzo <rizzo@iet.=
unipi.it>; Alan Somers <asomers@freebsd.org> =0ACc: Jack F Vogel <jfv@freeb=
sd.org>; Justin T. Gibbs <gibbs@freebsd.org>; Andre Oppermann <andre@freebs=
d.org>; "net@freebsd.org" <net@freebsd.org> =0ASent: Saturday, August 31, 2=
013 9:38 PM=0ASubject: RE: Flow ID, LACP, and igb=0A =0A=0AOn Sat, Aug 31, =
2013 at 8:41 AM, Barney Cordoba <barney_cordoba@yahoo.com> wrote:=0A=0A> Al=
so, the *most* important thing is distribution with realistic data. The goa=
l=0A> should be to use the most trivial function that gives the most balanc=
ed=0A> distribution with real numbers. Faster is not better if the result i=
s an=0A> unbalanced distribution.=0A=0AAgreed, with a caveat.=A0 It's criti=
cal that this distribution be by "flow", so=0Athat out of order packet deli=
very is minimized.=0A=0A> Many of your ports will be 80 and 53, and if you'=
re going through a router=0A> your ethernets may not be very unique, so why=
 even bother to include them?=0A> Does getting a good distribution require =
that you hash every element=0A> individually, or can you get the same distr=
ibution with a faster, simpler way=0A> of creating the seed?=0A>=0A> There'=
s also the other consideration of packet size. Packets on port 53 are=0A> l=
ikely to be smaller than packets on port 80. What you want is equal=0A> dis=
tribution PER PORT on the ports that will carry that vast majority of your=
=0A> traffic.=0A=0AUnfortunately, trying to evenly distribute traffic per p=
ort based on packet=0Asize will likely result in the reordering of packets,=
 and bandwidth wasted on=0ATCP retransmissions.=0A=0A> Or better yet, use t=
he same number of queues on igb as you have LAGG ports,=0A> and use the que=
ue id (or RSS) as the hash, so that your traffic is sync'd=0A> between the =
ethernet adapter queues and the LAGG ports. The card has already=0A> done t=
he work for you.=0A=0AIsn't this hash for selecting an outbound link?=A0 Th=
e ingress adapter hash (RSS)=0Awon't help for packets originating from the =
host, or for packets that may have=0Abeen translated or otherwise modified =
while traversing the stack.=0A=0AT.C.=0A___________________________________=
____________=0Afreebsd-net@freebsd.org mailing list=0Ahttp://lists.freebsd.=
org/mailman/listinfo/freebsd-net=0ATo unsubscribe, send any mail to "freebs=
d-net-unsubscribe@freebsd.org"
From owner-freebsd-net@FreeBSD.ORG  Sun Sep  1 02:27:30 2013
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTP id 26ECF1A9;
 Sun,  1 Sep 2013 02:27:30 +0000 (UTC)
 (envelope-from rizzo.unipi@gmail.com)
Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com
 [IPv6:2a00:1450:4010:c04::22d])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (No client certificate requested)
 by mx1.freebsd.org (Postfix) with ESMTPS id BDF532FFD;
 Sun,  1 Sep 2013 02:27:28 +0000 (UTC)
Received: by mail-lb0-f173.google.com with SMTP id o14so2863597lbi.32
 for <multiple recipients>; Sat, 31 Aug 2013 19:27:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:sender:in-reply-to:references:date:message-id:subject
 :from:to:cc:content-type;
 bh=Ylc3iq3b1QlBvxdTgYhUgUqLOYU0kK7Dv2264U9ZG1k=;
 b=aHY+jNZ7CRomOgDJ0DjWOp9DZwfGq0D2aEaI1E7mBMy2aD0MFFw2z7LDjetbuFI/XL
 zPiq3hDfcDlZLV6jf041gpCCUHWXMWQJfRxc9+f95a63+xRvrWCfd5coqV1a4XJYT9eq
 +AMuYXwoaY8XUgaVb0STpTXeXu9kYDP1W1eMRAuRa6O0G5+OvRK3H4VgNagW6CmmZDx+
 yJ9Yf/h/FWML3NNiO/sYC7CJyLi1Xi323yKSWMkP2dzXqKrDBVWVjbT3xYP1iuRvFg7g
 STqhbJxOcjFor3tl8NnRLVrJ6nXpU/d3hFl/hpkf11n6bbklV2xSv3vu1sGFr/15Topc
 YCEg==
MIME-Version: 1.0
X-Received: by 10.152.3.42 with SMTP id 10mr15000594laz.22.1378002445948; Sat,
 31 Aug 2013 19:27:25 -0700 (PDT)
Sender: rizzo.unipi@gmail.com
Received: by 10.114.200.165 with HTTP; Sat, 31 Aug 2013 19:27:25 -0700 (PDT)
In-Reply-To: <1378001733.36695.YahooMailNeo@web121606.mail.ne1.yahoo.com>
References: <D01A0CB2-B1E3-4F4B-97FA-4C821C0E3FD2@FreeBSD.org>
 <521BBD21.4070304@freebsd.org>
 <CAOtMX2jvKGY==t9i-a_8RtMAPH2p1VDj950nMHHouryoz3nbsA@mail.gmail.com>
 <521EE8DA.3060107@freebsd.org>
 <BCC2C62D4FE171479E2F1C2593FE508B0BE24383@BN-SCL-MBX03.Cudanet.local>
 <CAOtMX2h5SGh5eYV50y+QB_s367V9iattGU862wwXcONDV+TG8g@mail.gmail.com>
 <CA+hQ2+hgTaK1ZCOLGVFjSPY8nyNPHK4waSecyRQxR1gQcyjztg@mail.gmail.com>
 <1377952913.44129.YahooMailNeo@web121605.mail.ne1.yahoo.com>
 <BCC2C62D4FE171479E2F1C2593FE508B0BE2440B@BN-SCL-MBX03.Cudanet.local>
 <1378001733.36695.YahooMailNeo@web121606.mail.ne1.yahoo.com>
Date: Sun, 1 Sep 2013 04:27:25 +0200
X-Google-Sender-Auth: uHUCtpiAk6eN9tIh6b_OBc3skCM
Message-ID: <CA+hQ2+j-DDuEX1KCDYioCactjL71p-d4AtusPUfePrswDyUpog@mail.gmail.com>
Subject: Re: Flow ID, LACP, and igb
From: Luigi Rizzo <rizzo@iet.unipi.it>
To: Barney Cordoba <barney_cordoba@yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1
X-Content-Filtered-By: Mailman/MimeDel 2.1.14
Cc: Andre Oppermann <andre@freebsd.org>, Alan Somers <asomers@freebsd.org>,
 "net@freebsd.org" <net@freebsd.org>, Jack F Vogel <jfv@freebsd.org>,
 "Justin T. Gibbs" <gibbs@freebsd.org>,
 "T.C. Gubatayao" <tgubatayao@barracuda.com>
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-net>,
 <mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>;
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
 <mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Sep 2013 02:27:30 -0000

On Sun, Sep 1, 2013 at 4:15 AM, Barney Cordoba <barney_cordoba@yahoo.com>wrote:

> ...
>

[your point on testing with realistic assumptions is surely a valid one]


>
> Of course there's nothing really wrong with OOO packets. We had this
> discussion before; lots of people
> have round robin dual homing without any ill effects. It's just not an
> issue.
>

It depends on where you are.
It may not be an issue if the reordering is not large enough to
trigger retransmissions, but even then it is annoying as it causes
more work in the endpoint -- it prevents LRO from working, and even
on the host stack it takes more work to sort where an out of order
segment goes than appending an in-order one to the socket buffer.

cheers
luigi



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1378001733.36695.YahooMailNeo>