05.01.2018 6:37, Steven Hartland wrote: > Our TCP stack seems fragile during setup to out of order packets > which this multipath behavior causes, we've seen this on our loadbalancers > which is what triggered the investigation. The concrete result is many > aborted TCP connections, > over 300k ~2% on the machine I'm looking at.
This is another problem that needs to be fixed in general and not hidden under the carpet. Meantime, practical problems you see can be solved locally with any settings you like. > 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. _______________________________________________ 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"
