05.01.2018 22:13, 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. >>> 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. _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
