[patch][lagg] - Set a better granularity and distribution on roundrobin protocol.

[Marcelo Araujo]

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.

Best Regards,




2014-06-24 10:40 GMT+08:00 Marcelo Araujo <araujobsdport at gmail.com>:

>
>
> 2014-06-24 6:54 GMT+08:00 Adrian Chadd <adrian at 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 at FreeBSD.org     \\\'',)http://www.FreeBSD.org <http://www.freebsd.org/>   \/  \ ^
> Power To Server.         .\. /_)
>
>


-- 

-- 
Marcelo Araujo            (__)araujo at FreeBSD.org
\\\'',)http://www.FreeBSD.org <http://www.freebsd.org/>   \/  \ ^
Power To Server.         .\. /_)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: if_lagg-rr.patch
Type: application/octet-stream
Size: 3034 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20140718/f34ed737/attachment.obj>