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"