Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 8 Dec 2022 09:42:01 +0800 (CST)
Message-ID: <202212080942014374852@zte.com.cn>
In-Reply-To: <20221207172321.7da162c7@kernel.org>
References: 20221207153256.6c0ec51a@kernel.org,20221207172321.7da162c7@kernel.org
Mime-Version: 1.0
From:   <yang.yang29@zte.com.cn>
To:     <kuba@kernel.org>
Cc:     <edumazet@google.com>, <davem@davemloft.net>, <pabeni@redhat.com>,
        <bigeasy@linutronix.de>, <imagedong@tencent.com>,
        <kuniyu@amazon.com>, <petrm@nvidia.com>, <liu3101@purdue.edu>,
        <wujianguo@chinatelecom.cn>, <netdev@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>, <tedheadster@gmail.com>
Subject: =?UTF-8?B?UmU6IFtQQVRDSCBsaW51eC1uZXh0XSBuZXQ6IHJlY29yZCB0aW1lcyBvZiBuZXRkZXZfYnVkZ2V0IGV4aGF1c3RlZA==?=
Content-Type: text/plain;
        charset="UTF-8"
Precedence: bulk

> ime_squeeze is a terrible metric, if you can find a direct metric
> in terms of application latency or max PPS, that's much more valuable.

Actually we are working on measure the latency of packets between
inqueue and dequeue in eBPF way, we add new tracepoint to help
do that. And we are also consider using PSI to measure it. 

We will submit patches when it's ready, thanks!