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 > > Best Regards, > > > > > 2014-06-24 10:40 GMT+08:00 Marcelo Araujo <araujobsdp...@gmail.com>: > >> >> >> 2014-06-24 6:54 GMT+08:00 Adrian Chadd <adr...@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 (__) >> ara...@freebsd.org \\\'',)http://www.FreeBSD.org >> <http://www.freebsd.org/> \/ \ ^ >> Power To Server. .\. /_) >> >> > > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
