On 16/11/2015 07:07, Eric Dumazet wrote:
On Sun, 2015-11-15 at 16:58 -0800, Grant Zhang wrote:
Hi Patrick,
Have you tried the two patches Eric mentioned? One of my 4.1.11 server
just hanged with very similar stack trace and I am wondering whether the
aforementioned patches would help.
Thanks
Hi Patrick,
Have you tried the two patches Eric mentioned? One of my 4.1.11 server
just hanged with very similar stack trace and I am wondering whether the
aforementioned patches would help.
Thanks,
Grant
On 23/09/2015 09:31, Eric Dumazet wrote:
On Wed, 2015-09-23 at 10:25 +0200, Patrick
On 08/10/2015 19:33, Eric Dumazet wrote:
As promised in last patch series, we implement a better SO_REUSEPORT
strategy, based on cpu affinities if selected by the application.
We also moved sk_refcnt out of the cache line containing the lookup
keys, as it was considerably slowing down smp
Hi Martin,
I did try out your v2 patch on our production server and can confirm
that the patch gets rid of the WARN_ON trace.
I would really like to see the issue been fixed by upstream(and
backported to kernel longterm tree 3.14)--either by this patch or
something else. Is there a plan for
to let me know.
Thanks,
Grant
On 5/30/15 4:08 PM, Neal Cardwell wrote:
On Sat, May 30, 2015 at 2:52 PM, Grant Zhang gzh...@fastly.com wrote:
Thank you Neal. Most likely I will test the patch on Monday and report
back the result.
As for the TcpExtTCPSACKReneging counter, attached
wrote:
Hi Grant,
On Thu, Jun 04, 2015 at 09:35:04AM -0700, Grant Zhang wrote:
Hi Neal,
Unfortunately with the patch we still see the same stack trace.
Attached is the TcpExtTCPSACKReneging with the patch, captured with
60 seconds interval. Its value is incremented at an similar speed as
before
, Neal Cardwell ncardw...@google.com wrote:
On Fri, May 29, 2015 at 3:53 PM, Grant Zhang gzh...@fastly.com wrote:
Hi Neal,
I will be more happy to test the patch. Please send it my way.
Great. Thank you so much for being willing to do this. Attached is a
patch for testing. I generated
We have multiple machines running into the following trace repeatedly. The
trace shows up every couple of seconds on our production machines.
May 29 18:14:04 cache-fra1230 kernel:[3080455.796143] WARNING: CPU: 7 PID: 0 at
net/ipv4/tcp_output.c:1082 tcp_fragment+0x2e4/0x2f0()
May 29 18:14:04
Hi Neal,
I will be more happy to test the patch. Please send it my way.
Thanks,
Grant
On May 29, 2015, at 12:46 PM, Neal Cardwell ncardw...@google.com wrote:
On Fri, May 29, 2015 at 3:21 PM, Grant Zhang gzh...@fastly.com wrote:
We have multiple machines running into the following trace
