Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 29 Jul 2014 12:03:12 +0800
From:      Marcelo Araujo <araujobsdport@gmail.com>
To:        FreeBSD Net <freebsd-net@freebsd.org>
Subject:   Re: [patch][lagg] - Set a better granularity and distribution on roundrobin protocol.
Message-ID:  <CAOfEmZihzf9S5eGV%2BJFoNt7BQ3YUJhbpFYPfi9RGp5TQRP3ymw@mail.gmail.com>

next in thread | raw e-mail | index | archive | help
>
>
> >
> > 2014-07-19 2:18 GMT+08:00 Navdeep Parhar <nparhar@gmail.com
> > <mailto: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?
>

Hey np@


>
> Are you saying lagg's roundrobin implementation is already spraying
> packets for the same flow across interfaces?


Yes it does, if you check the SACK counter you can see that it does out of
order by itself, with the patch or without the patch. The only thing that
this patch helps is, send more packets throughout an interface before
switch to the next one, and we will end up with less SACK and a better
throughput, and also we can make a fine tuning.


> That would make it
> unsuitable for anything TCP.


This is something that everybody knows, it breaks TCP by itself, I mean,
performance will drop.


> But then your patch isn't making it any
> worse so I don't have any objection to it any more.
>

Thank you so much, and sorry by my late reply, I got busy testing other
things.


>
> Looks like loadbalance does the right thing for flows.
>

Yes, loadbalance has no issue, it is mainly on round robin.

Best Regards,


-- 
Marcelo Araujo            (__)araujo@FreeBSD.org
\\\'',)http://www.FreeBSD.org <http://www.freebsd.org/>;   \/  \ ^
Power To Server.         .\. /_)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOfEmZihzf9S5eGV%2BJFoNt7BQ3YUJhbpFYPfi9RGp5TQRP3ymw>