Date: Thu, 3 Sep 2015 16:08:28 -0700 From: Garrett Cooper <yaneurabeya@gmail.com> To: Jeff Meegan <jeffm@frob.org> Cc: Jack Vogel <jfvogel@gmail.com>, "K. Macy" <kmacy@freebsd.org>, "net@freebsd.org" <net@freebsd.org>, Hrishikesh Keremane <hr1sh1@yahoo.com>, "hackers@freebsd.org" <hackers@freebsd.org>, Vijay Singh <vijju.singh@gmail.com> Subject: Re: GPL issues around OFED code in FreeBSD 9.1 Message-ID: <B1BC39E3-6AEA-4759-B7C0-F506E5972E4C@gmail.com> In-Reply-To: <7FF6BFC8-0031-4E40-AB38-75B5FD4EF466@frob.org> References: <5BFB9010-159A-44EE-BB9A-A4E445383AA2@yahoo.com> <C0A50BDF-6AD3-4006-B954-66385F8DACD0@gmail.com> <CALCNsJT-XLY2MpxOs4Ls=GLX8r16bBXyMjUU4Nnj%2BwXRBcwidA@mail.gmail.com> <CAHM0Q_NGttERk%2BmaOz9V5-FXD5krRcZ5zGLsqLG7ooTzmzAn0A@mail.gmail.com> <CAFOYbcmp%2BSVMjsm9knD8BxZ5Sk09RDGQ66Oko1E6t-zJY-d-Dw@mail.gmail.com> <7FF6BFC8-0031-4E40-AB38-75B5FD4EF466@frob.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Sep 3, 2015, at 13:18, Jeff Meegan <jeffm@frob.org> wrote: > > According to their EULA, it is BSD licensed. > > http://www.mellanox.com/page/mlnx_ofed_eula?mtag=linux_sw_drivers Yes, but the 9.1 version wasn't strictly from Mellanox.. I don't know if I'd use the pre-Mellanox version though, tbh. Thanks, -NGie From owner-freebsd-net@freebsd.org Thu Sep 3 23:32:31 2015 Return-Path: <owner-freebsd-net@freebsd.org> 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 1080B9CAF13 for <freebsd-net@mailman.ysv.freebsd.org>; Thu, 3 Sep 2015 23:32:31 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E7EAF18C; Thu, 3 Sep 2015 23:32:30 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id 9F542CCD45; Thu, 3 Sep 2015 16:32:29 -0700 (PDT) Date: Thu, 3 Sep 2015 16:32:29 -0700 From: hiren panchasara <hiren@strugglingcoder.info> To: Lawrence Stewart <lstewart@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: Value of congestion window (cwnd) when loss is detected Message-ID: <20150903233229.GT68814@strugglingcoder.info> References: <20150903005405.GN68814@strugglingcoder.info> <55E82B59.6000202@freebsd.org> <20150903161651.GQ68814@strugglingcoder.info> <20150903175313.GS68814@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="U8v/hV883cEE9JJG" Content-Disposition: inline In-Reply-To: <20150903175313.GS68814@strugglingcoder.info> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org> List-Unsubscribe: <https://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: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>, <mailto:freebsd-net-request@freebsd.org?subject=subscribe> X-List-Received-Date: Thu, 03 Sep 2015 23:32:31 -0000 --U8v/hV883cEE9JJG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 09/03/15 at 10:53P, hiren panchasara wrote: > On 09/03/15 at 09:16P, hiren panchasara wrote: > > On 09/03/15 at 09:13P, Lawrence Stewart wrote: > [skip] > > >=20 > > > You want to read up about window inflation during fast recovery in RFC > > > 5681 followed by 3782, and then consult Stevens vol 2 to understand h= ow > > > variables are used for different purposes depending on connection sta= te > > > and which code path was taken (something I greatly dislike and would > > > love to change one day). >=20 > Here is my understanding of these rfcs: > RFC 5681: > 3.2. Fast Retransmit/Fast Recovery > When we detect loss: > 2. When the third duplicate ACK is received, a TCP MUST set ssthresh to > no more than the value given in equation (4). When [RFC3042]is in use, > additional data sent in limited transmit MUST NOT be included in this > calculation. >=20 > ssthresh =3D max (FlightSize / 2, 2*SMSS) <-- equation (4). > In my example, > ssthresh =3D max (14480 / 2, 2*1448) =3D 7240. i.e. 5 packets >=20 > 3. The lost segment starting at SND.UNA MUST be retransmitted and cwnd > set to ssthresh plus 3*SMSS. This artificially "inflates" the > congestion window by the number of segments (three) that haveleft the > network and which the receiver has buffered. >=20 > cwnd =3D (ssthresh + 3*SMSS) > In my example, > cwnd =3D 7240 + 3*1448 =3D 11584, i,e, 8 packets >=20 > RFC 3782: > We either do sack based recovery *or* newreno based recovery. And we do > sack based when TF_SACK_PERMIT is present. > So I don't think this comes into play. Please correct me if that is not t= he > case. >=20 > Stevens vol 2: >=20 > sshthresh: > "When t_dupacks reaches 3 ( tcprexmtthresh ), the value of snd_nxt is > saved in onxt and the slow start threshold ( ssthresh ) is set to one-half > the current congestion window, with a minimum value of two segments." >=20 > snd_cwnd: > The congestion window is set to the slow start threshold plus the number > of segments that the other end has cached. By cached we mean the number > of out-of-order segments that the other end has received and generated > duplicate ACKs for. These cannot be passed to the process at the other > end until the missing segment (which was just sent) is received. >=20 > So, according to this, sshthresh itself is set pretty high i.e. cwnd/2. > And, snd_cwnd =3D sshthresh + cached packets at the other end. >=20 > In my example, when server realizes loss, cwnd is 17377 i.e. 12 packets. > Half of that is 6 packets. And cached packets is 2 because the dup acks > we got were for 'ack 2897'. So, according to stevens, snd_cwnd should > have been 6+2 =3D 8 packets. Which matches up to what RFC 5681 suggests. My interpretation of cached packets is wrong here. It should be the packets that receiver *cannot* send up the stack. Receiver told us via SACK (sack 1 {4345:10137}) that it has got at least up to 10137, i.e. 7 packets. And cumulative ack is 2897, i.e. 2 packets. So cached packets at the receiver that it cannot send up comes out to be 5 packets. According to this, the snd_cwnd should be 6(ssthresh) + 5(cached) =3D 11 pa= ckets. Cheers, Hiren --U8v/hV883cEE9JJG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJV6NiNXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lTkAH/1wSoKTNbrFEcuZnbWVM/w+D FXeSG/7J/+WuOclkxNHVM2eDG4UBPYB0ANke/E8Cs4+MJ51AotSosprI76bJ58QO wq43P5oWCn22JPq/vEfMQCSF2AF710io2yz8XlTpuiyXpoF5SGbbkSXaaO0CcThX jv52DAtSV+TqQJ86YV2m8GbyEFhxH7bThuA018/WVpLbpk3zdiTPO+ynvw/5Vev/ 0KkBtvqAsTLtcoPDeBf1QbvF0SOGKW5B6oMyHHB3uWdCBU/soDvdXd5/EZJRIIU+ KJa5xE7DECTuuLDgMSZdFDn2LeROeSyXA6RvLx6KnOqRRXheijYhrcrh8w5l0co= =fRAN -----END PGP SIGNATURE----- --U8v/hV883cEE9JJG--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B1BC39E3-6AEA-4759-B7C0-F506E5972E4C>