06.01.2018 0:12, Steven Hartland wrote:

>>>>>>> I hope there's some improvements that can be made, for example if we 
>>>>>>> can determine
>>>>>>> the stream was instigated remotely then flowid would always be valid 
>>>>>>> hence we can use it assuming it
>>>>>>> matches the requested spec or if we can make it clear to the user that 
>>>>>>> laggproto is not the one they requested, I'm open to ideas?
>>>>>> We just need to clear flow id from incoming TCP segments and always 
>>>>>> generate new flow id for responses
>>>>>> keeping old flow id for IP forwarding case. Please back out your change 
>>>>>> to not degrade IP forwarding performance.
>>>>> Sorry I don't follow you. You seem to be inferring that we can easily 
>>>>> generate a flowid without involving the sending hardware
>>>> RSS has nothing to do with sending hardware. It's operating system's job 
>>>> to choose outgoing port, not hardware's job.
>>> The OS is deciding which outgoing, however its using the hash based on the 
>>> flowid to do so
>> It should use flowid for transit forwarding IP packet only. It should not 
>> use flowid from incoming TCP segment.
> Not sure I follow your meaning, LACP has nothing to do with incoming TCP, its 
> balancing and hence hashing is performed on outbound (tx) traffic only.

You stated that incoming TCP's flowid has influence for outbound responses. It 
should not.

>>>>> I can't see how that is possible as that's chicken and egg i.e. you can't 
>>>>> get the HW interface
>>>>> to generate the flowid without sending a packet and you can't send a 
>>>>> packet
>>>>> until you have a the flowid to decide which interface to send it from.
>>>> Outgoing packet flow does not and should not depend on incoming flow,
>>>> they are independent things in case of LACP. There is no "chicken and egg" 
>>>> problem at all.
>>>>
>>> But this is how it works ATM, it uses the flowid which is only valid after 
>>> the first rx.
>> Then this is a bug that should be fixed to solve your problem,
>> instead of change of lagg defaults that degrades IP forwarding performance.
> You seem to be confusing IP forwarding with choice of port in the lagg 
> interface?

Choice of outgoing port is performed in case of IP forwarding too.
Performance of IP forwarding degrades with your change, that's why I ask you to 
backout it.

_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Reply via email to