[ cc Andrei who reported a similar trace ] On 10/16/17 6:50 PM, Yuchung Cheng wrote: > On Mon, Oct 16, 2017 at 3:38 PM, David Ahern <dsah...@gmail.com> wrote: >> I need to throw this one over the fence. I triggered the trace below >> testing changes to the tcp tracepoint. It is not readily reproducible >> and does not appear to be correlated to the perf session. > We're seeing this internally at Google a lot as well. The culprit is > because TCP tries to measure/track reordering in precise packet > distance (tp->reordering). That's difficult but also fairly useless to > get right because that highly depends on the instantaneous > traffic load and L2/pathing behavior. In other words the previous > reordering degree has little bearing for my next reordering based on > our analysis. The > warning itself has minor to no impact on TCP performance or > reliability. > > I am testing a patch to replace that approach (and remove the > warning). Should be ready soon. >
Thanks for the update.
