Date: Fri, 18 Jul 2014 20:28:09 -0700 From: Adrian Chadd <adrian@freebsd.org> To: araujo@freebsd.org Cc: FreeBSD Net <freebsd-net@freebsd.org>, Navdeep Parhar <nparhar@gmail.com> Subject: Re: [patch][lagg] - Set a better granularity and distribution on roundrobin protocol. Message-ID: <CAJ-VmonNuu5YunzZjUYsMFK9rFMbTf7=nswpPisjwV-RpoHzRA@mail.gmail.com> In-Reply-To: <CAOfEmZigg8_3b073aEU7kJd9i%2BjLFOVvAV_V4aU0jHOAJGLVBg@mail.gmail.com> References: <CAOfEmZjmb1bdvn0gR6vD1WeP8o8g7KwXod4TE0iJfa=nicyeng@mail.gmail.com> <CAJ-Vmomt2QDXAVBVUk6m8oH4Pa5yErDdG6wWrP3X7%2BDW137xiA@mail.gmail.com> <CAOfEmZja8Tkv_xG8LyR5Nbj%2BOga=vvdy=b3pxHqZi0-BBq25Uw@mail.gmail.com> <CAJ-VmomY2wP1EyVK4J16sGmMid=sJ9MPZrUY6pgcKGBDXm1T4g@mail.gmail.com> <CAOfEmZj5pk7bFB-PBqaJsi%2BbA73gbsUZzqggs4yEVky3_61NpQ@mail.gmail.com> <CAOfEmZhtZCettzD6pKQMHRiQE42nQmBuimOq28cA23R%2BYyc13w@mail.gmail.com> <53C964F7.8060503@gmail.com> <CAOfEmZigg8_3b073aEU7kJd9i%2BjLFOVvAV_V4aU0jHOAJGLVBg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 18 July 2014 19:06, Marcelo Araujo <araujobsdport@gmail.com> wrote: > > > > 2014-07-19 2:18 GMT+08:00 Navdeep Parhar <nparhar@gmail.com>: > >> On 07/18/14 00:49, Marcelo Araujo wrote: >> > Hello guys, >> > >> > I made few changes on the lagg(4) patch. Also, I made tests using >> > igb(4), >> > ixgbe(4) and em(4); seems everything worked pretty well. >> > >> > I'm wondering if anyone else could make a review, and what I need to do, >> > to >> > see this patch committed. >> >> Deliberately putting out-of-order packets on the wire is never a good >> idea. This would count as a serious regression in lagg(4) imho. >> >> Regards, >> Navdeep >> >> > > I'm wondering if anyone have tested the patch; because as I have explained > in another email, the number of SACK is much less with this patch. I have > put some pcap files here: http://people.freebsd.org/~araujo/lagg/ > > Also, as far as I know, the current roundrobin implementation has no such > kind of mechanism to control the order of the packages that goes to the > wire. And this patch, what it only does is, instead to send only one package > through one interface and switch to the another one, it will send X(where X > is the number of packets defined via sysctl) packets and then, switch to the > next interface. > > So, could you show me, where this patch deliberately put out-of-order > packets? Did I miss anything? It doesn't introduce it, but it still continues potentially out of order behaviour depending upon CPU loading and NIC scheduling. If you're seeing reduced ACK / retransmits by doing this then there's gotta be some other underlying factor causing it. That's what I think needs to be fixed, not papering over it by more round robin hacks. :-P -a
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmonNuu5YunzZjUYsMFK9rFMbTf7=nswpPisjwV-RpoHzRA>