Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp4536971imj; Tue, 12 Feb 2019 18:48:57 -0800 (PST) X-Google-Smtp-Source: AHgI3IZ6wIbY2x3z5kGtAEb/rev09IGKV1Ma0XA3upz1hnBWbbn/neDtxpOKkXndWg9rYS92e/2v X-Received: by 2002:a62:6047:: with SMTP id u68mr7107041pfb.239.1550026137886; Tue, 12 Feb 2019 18:48:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550026137; cv=none; d=google.com; s=arc-20160816; b=Bazaf4ayzkKoZsnhwEmSQLNgk11DfEUy4tuf0tlHcOYSUZH33qQUARKzSkWuBgWmdS 8DJ9shNdtkr+utJIoICK8x8DAbWSednZIk/hzUCKb/NZro92xWIqoefKqnBt/qgR5y2I teBd9HV8Q+i852KW+aE1mqADOT3JxKA/uX88W7AA7i9rA61zVUteQaok60x1JXw3IjlN gqvT+iEPCBmf1JzjDsIuA/2o7eq3z4K8aKYoQbV8BsIV6FSinb1HtvHETDcSf3imyrwN pjFwUJD5E+NMRm1eggzYDbryczUhlD3bdqLptLdQ1Yklhy0mDW+b6CGhgYr+vlglSFHW T3WQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=X1DWd8/tKpU2pyvWFgPd32wgFX3JllDhgcMA7u9cW20=; b=AgXpWNSjnBsFum4L1yeVIReRKoG8CJOgDK5qCVLT6OVOL7qEC+RG9WaT05m6fsOcbJ gNdEqEkF7UdW3qtKbYcGAovVbktpqhRlYfCCmR6Oi6liEDWVfpJw1e9KMyevrhhhE6oN DXT6gJlp4iLK2sIujFV15tN0fu+PuAkKMz+/qx0okzAzwXKoYpvf1L79j9b8IVbfhGCr 67pI1b+3u2AuhVEAv5erw9okYBOdz8iTrKmobxOzhh3ahJ0nr4GyN8GuFjO9H22lwTWL HQCehDms+G8QuxiyVSbulSchLGi5RknwJzUePUs8UZ6UB4cHR3ESOhMwepyKYk03UFbX t7rA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=pNMvnrM3; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a9si14364283plp.323.2019.02.12.18.48.42; Tue, 12 Feb 2019 18:48:57 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=pNMvnrM3; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388991AbfBMCro (ORCPT + 99 others); Tue, 12 Feb 2019 21:47:44 -0500 Received: from mail-it1-f195.google.com ([209.85.166.195]:50371 "EHLO mail-it1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732993AbfBMCrg (ORCPT ); Tue, 12 Feb 2019 21:47:36 -0500 Received: by mail-it1-f195.google.com with SMTP id z7so2222433iti.0; Tue, 12 Feb 2019 18:47:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=X1DWd8/tKpU2pyvWFgPd32wgFX3JllDhgcMA7u9cW20=; b=pNMvnrM3qy/hbUTRJQG60Fg4zMNGE0k3kbvjvMQavzGUSp3fAs8yKtDDDgcezVfnWj /zK2Q4ZiGHS9oLC1wbMzqR60xymrFbFRA9TsumaMU8mgKTkbIbLHTYPKkL7TP7w+KetZ SQ4JR2WMrKEcLSIl1nhG57IME/XMGtAETNxXgkHhR18KWYh/oLb092AhQcbwoTRV9PiH rFulMKF4RwxlJ16CjppBx4QXNOTO4c8u/cXFReqflbKk1V4rXsTQr3N6g0+yKWz2d1rR ZO4VGvr/5unQj2tyyJd/s8DtVGKXY1n/rH5yEYDLYuhfq0Ub4jEae5s9E2TZaNv8xjXL XJnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=X1DWd8/tKpU2pyvWFgPd32wgFX3JllDhgcMA7u9cW20=; b=ZjXnffQBg7bVxVBgyA9fRYed9sHv3A5PyshrCwomNCIFMSyTvOnUjThbge1U//fGT/ hLscIRRwvYkyA+TbEoQsPdy6NK7WbW9ZSjISHv1/Kwj3DQitcFLoW18BqKE2i2FVXNgK jWVC1fRml05CfF3TpWncbwBuz2ZWvmml7A9hPTQ+C7+Dg3ENfSyEY0qV+brhLgx458uL 9VBJBiJqtwM5lokCJVSt3gshZCCg91u50Q+b54s0ZPZSC3vqcRZNZK+az98YKY93ImF2 eKxCz3Q1mSfMmJH4w8n7YsyRhNe9udHwsX1FO03rc2Zv+9W1YpIQVp9EUMAd3KfCv6zz gNaw== X-Gm-Message-State: AHQUAuYpT7yq2bKVzS5c3P2o/1pTyJWZl4kMCIuK5JLOsBsyYefWVmUz wPJaxHnI7JFUaR/rWT2bPAvV1N9kd/ouicDG9Tk= X-Received: by 2002:a24:e44:: with SMTP id 65mr959158ite.154.1550026055687; Tue, 12 Feb 2019 18:47:35 -0800 (PST) MIME-Version: 1.0 References: <1549971097-12627-1-git-send-email-laoar.shao@gmail.com> <1549971097-12627-2-git-send-email-laoar.shao@gmail.com> <38d07cb3-b767-bfc4-9ae5-48367971d839@gmail.com> In-Reply-To: From: Yafang Shao Date: Wed, 13 Feb 2019 10:46:59 +0800 Message-ID: Subject: Re: [bpf-next 1/2] tcp: replace SOCK_DEBUG() with tcp_stats() To: Eric Dumazet Cc: Eric Dumazet , Daniel Borkmann , Alexei Starovoitov , Yonghong Song , Lawrence Brakmo , David Miller , netdev , LKML , shaoyafang@didiglobal.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 13, 2019 at 10:15 AM Eric Dumazet wrote: > > On Tue, Feb 12, 2019 at 6:07 PM Yafang Shao wrote: > > > > > Let me explain the background for you. > > I want to track some TCP abnormal behavior in TCP/IP stack. But I > > find there's no good way to do it. > > The current MIBs are per net, other than per socket, that makes it not > > very powerful. > > And the ancient SOCK_DEBUG is not good as well. > > So we think why not cleanup this ancient SOCK_DEBUG() and introduce a > > more powerful method. > > > I am all for it, but this more powerful method does nothing at all in > the current patches. > > I can not accept patches just because they seem to be harmless, > knowing that the next patches > will be pushed later changing more stuff, just because the new > infrastructure is there "and can be used" > > Just remove all SOCK_DEBUG() calls, there are leftovers of very ancient times. > OK. I will send a patch for it. > Do not add more debugging stuff unless you can demonstrate > they actually allowed you to find a real bug and that you sent a > public fix for it. > Sure. > Just adding "cool stuff" in TCP stack does not please me, it is only > more complexity for unproven gain. > > Otherwise, I am tempted to think that these BPF hooks are there only > so that a company can more > easily build a private variant of TCP, yet letting the community > maintaining the hard part of TCP stack. :-) > > Thank you. Thanks Yafang