svn commit: r327559 - in head: . sys/net

[Steven Hartland]

On 05/01/2018 13:11, Slawa Olhovchenkov wrote:
> On Fri, Jan 05, 2018 at 03:50:31AM +0700, Eugene Grosbein wrote:
>
>> 05.01.2018 3:05, Steven Hartland wrote:
>>
>>> Author: smh
>>> Date: Thu Jan  4 20:05:47 2018
>>> New Revision: 327559
>>> URL: https://svnweb.freebsd.org/changeset/base/327559
>>>
>>> Log:
>>>    Disabled the use of flowid for lagg by default
>>>    
>>>    Disabled the use of RSS hash from the network card aka flowid for
>>>    lagg(4) interfaces by default as it's currently incompatible with
>>>    the lacp and loadbalance protocols.
>>>    
>>>    The incompatibility is due to the fact that the flowid isn't know
>>>    for the first packet of a new outbound stream which can result in
>>>    the hash calculation method changing and hence a stream being
>>>    incorrectly split across multiple interfaces during normal
>>>    operation.
>>>    
>>>    This can be re-enabled by setting the following in loader.conf:
>>>    net.link.lagg.default_use_flowid="1"
>>>    
>>>    Discussed with: kmacy
>>>    Sponsored by:	Multiplay
>> RSS by definition has meaning to received stream. What is "outbound" stream
>> in this context, why can the hash calculatiom method change and what exactly
>> does it mean "a stream being incorrectly split"?
>>
>> Defaults should not be changed so easily just because they are not optimal
>> for some specific case. Each lagg has its own setting for flowid usage
>> and why one cannot just use "ifconfig lagg0 -use_flowid" for such cases?
> Irrelevant to RSS and etc. flowid distribution in lacp case work very
> bad. This is good and must be MFC (IMHO).
There was no concrete conclusion to this thread and I've not had time to 
look into this more and it's on my open list to MFC to stable/11 in time 
for 11.2.

Even given the drop in performance, I think we should prefer correctness 
over increased performance and given the new default can still be 
overridden in loader.conf I'm looking to MFC this shortly unless I get 
any strong objections with a clear path forward.

     Regards
     Steve