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

Eugene Grosbein eugen at grosbein.net
Fri Jan 5 17:28:52 UTC 2018


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.



More information about the svn-src-head mailing list