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

Adrian Chadd adrian at freebsd.org
Sat Jul 19 03:28:11 UTC 2014


On 18 July 2014 19:06, Marcelo Araujo <araujobsdport at gmail.com> wrote:
>
>
>
> 2014-07-19 2:18 GMT+08:00 Navdeep Parhar <nparhar at 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


More information about the freebsd-net mailing list