Hi Eric, On 11/20/2018 02:49 PM, Eric Dumazet wrote: > On 11/20/2018 02:17 AM, Paolo Abeni wrote: >> Eric noted that with UDP GRO and napi timeout, we could keep a single >> UDP packet inside the GRO hash forever, if the related NAPI instance >> calls napi_gro_complete() at an higher frequency than the napi timeout. >> Willem noted that even TCP packets could be trapped there, till the >> next retransmission. >> This patch tries to address the issue, flushing the oldest packets before >> scheduling the NAPI timeout. The rationale is that such a timeout should be >> well below a jiffy and we are not flushing packets eligible for sane GRO. >> >> Reported-by: Eric Dumazet <eric.duma...@gmail.com> >> Signed-off-by: Paolo Abeni <pab...@redhat.com> >> --- >> Sending as RFC, as I fear I'm missing some relevant pieces. >> Also I'm unsure if this should considered a fixes for "udp: implement >> GRO for plain UDP sockets." or for "net: gro: add a per device gro flush >> timer" > > You can add both, now worries. > > Google DC TCP forces a PSH flag on all TSO packets, so for us the flush is > done > because of the PSH flag, not upon a timer/jiffie.
Any plans to upstream this change? Or is the concern that this should only be used DC internally? (If the latter, perhaps it would make sense to add this under DCTCP mode then?) Thanks a lot, Daniel
