Date: Tue, 24 Jun 2014 10:40:52 +0800 From: Marcelo Araujo <araujobsdport@gmail.com> To: Adrian Chadd <adrian@freebsd.org> Cc: FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: [patch][lagg] - Set a better granularity and distribution on roundrobin protocol. Message-ID: <CAOfEmZj5pk7bFB-PBqaJsi%2BbA73gbsUZzqggs4yEVky3_61NpQ@mail.gmail.com> In-Reply-To: <CAJ-VmomY2wP1EyVK4J16sGmMid=sJ9MPZrUY6pgcKGBDXm1T4g@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>
next in thread | previous in thread | raw e-mail | index | archive | help
2014-06-24 6:54 GMT+08:00 Adrian Chadd <adrian@freebsd.org>: > Hi, > > No, don't introduce out of order behaviour. Ever. Yes, it has out of order behavior; with my patch much less. I upload two pcap files and you can see by yourself, if you don't believe in what I'm talking about. Test done using: "iperf -s" and "iperf -c <ip> -i 1 -t 10". 1) Don't change the number of packets(default round robin behavior). http://people.freebsd.org/~araujo/lagg/lagg-nop.cap 8 out of order packets. Several SACKs. 2) Set the number of packets to 50. http://people.freebsd.org/~araujo/lagg/lagg.cap 0 out of order packets. Less SACKs. > You may not think > it's a problem for TCP, but UDP things and VPN things will start > getting very angry. There are VPN configurations out there that will > drop the VPN if frames are out of order. > I'm not thinking that will be a problem for TCP, but, in somehow it will be, less throughput as I showed before, and less SACK. About the VPN, please, tell me which softwares, and let me know where I can get a sample to make a testbed. However to be very honest, I don't believe anyone here when change something at network protocols will make this extensive testbed. It is almost impossible to predict what software it will works or not, and I don't believe anyone here has all these stuff in hands. > > The ixgbe driver is setting the flowid to the msix queue ID, rather > than a 32 bit unique flow id hash value for the flow. That makes it > hard to do traffic distribution where the flowid is available. > Thanks for the explanation. > > There's an lagg option to re-hash the mbuf rather than rely on the > flowid for outbound port choice - have you looked at using that? Did > that make any difference? > Yes, I set to 0 the net.link.lagg.0.use _flowid, it make a little difference to the default round robin implementation, but yet I can't reach more than 5 Gbit/s. With my patch and set the packets to 50, it improved a bit too. So, thank you so much for all review, I don't know if you have time and a testbed to make a real test, as I'm doing. I would be happy if you or more people could make tests on that patch. Also, I have only ixgbe(4) to make tests, would appreciate if this patch could be tested with other NICs too. 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?CAOfEmZj5pk7bFB-PBqaJsi%2BbA73gbsUZzqggs4yEVky3_61NpQ>