From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 27E52C04AB5 for ; Tue, 4 Jun 2019 02:31:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EA66124A1D for ; Tue, 4 Jun 2019 02:31:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726490AbfFDCbQ (ORCPT ); Mon, 3 Jun 2019 22:31:16 -0400 Received: from mailgw02.mediatek.com ([1.203.163.81]:63666 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726076AbfFDCbQ (ORCPT ); Mon, 3 Jun 2019 22:31:16 -0400 X-UUID: f291c6e07a734aa6b35d260fd5e5b799-20190604 X-UUID: f291c6e07a734aa6b35d260fd5e5b799-20190604 Received: from mtkcas35.mediatek.inc [(172.27.4.253)] by mailgw02.mediatek.com (envelope-from ) (mailgw01.mediatek.com ESMTP with TLS) with ESMTP id 1956888644; Tue, 04 Jun 2019 10:31:08 +0800 Received: from MTKCAS32.mediatek.inc (172.27.4.184) by MTKMBS31DR.mediatek.inc (172.27.6.102) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 4 Jun 2019 10:31:06 +0800 Received: from [10.17.3.153] (172.27.4.253) by MTKCAS32.mediatek.inc (172.27.4.170) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Tue, 4 Jun 2019 10:31:06 +0800 Message-ID: <1559615466.24897.106.camel@mhfsdcap03> Subject: RE: [v2, PATCH 3/4] net: stmmac: modify default value of tx-frames From: biao huang To: Jose Abreu CC: "davem@davemloft.net" , "andrew@lunn.ch" , Giuseppe Cavallaro , "Alexandre Torgue" , Maxime Coquelin , Matthias Brugger , "netdev@vger.kernel.org" , "linux-stm32@st-md-mailman.stormreply.com" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "linux-mediatek@lists.infradead.org" , "yt.shen@mediatek.com" , "jianguo.zhang@mediatek.com" , "boon.leong.ong@intel.com" Date: Tue, 4 Jun 2019 10:31:06 +0800 In-Reply-To: <78EB27739596EE489E55E81C33FEC33A0B93B6DF@DE02WEMBXB.internal.synopsys.com> References: <1559527086-7227-1-git-send-email-biao.huang@mediatek.com> <1559527086-7227-4-git-send-email-biao.huang@mediatek.com> <78EB27739596EE489E55E81C33FEC33A0B93B6DF@DE02WEMBXB.internal.synopsys.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-MTK: N Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2019-06-03 at 11:40 +0000, Jose Abreu wrote: > From: Biao Huang > > > the default value of tx-frames is 25, it's too late when > > passing tstamp to stack, then the ptp4l will fail: > > > > ptp4l -i eth0 -f gPTP.cfg -m > > ptp4l: selected /dev/ptp0 as PTP clock > > ptp4l: port 1: INITIALIZING to LISTENING on INITIALIZE > > ptp4l: port 0: INITIALIZING to LISTENING on INITIALIZE > > ptp4l: port 1: link up > > ptp4l: timed out while polling for tx timestamp > > ptp4l: increasing tx_timestamp_timeout may correct this issue, > > but it is likely caused by a driver bug > > ptp4l: port 1: send peer delay response failed > > ptp4l: port 1: LISTENING to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED) > > > > ptp4l tests pass when changing the tx-frames from 25 to 1 with > > ethtool -C option. > > It should be fine to set tx-frames default value to 1, so ptp4l will pass > > by default. > > I'm not sure if this is the right approach ... What's the timeout value > you have for TX Timestamp ? I use the default tx_timestamp_timeout value 1, which represents 1ms. do you try ptp4l on your side? performance test is done in https://lkml.org/lkml/2019/5/30/1617 and seems no performance degradation. > > Thanks, > Jose Miguel Abreu From mboxrd@z Thu Jan 1 00:00:00 1970 From: biao huang Subject: RE: [v2, PATCH 3/4] net: stmmac: modify default value of tx-frames Date: Tue, 4 Jun 2019 10:31:06 +0800 Message-ID: <1559615466.24897.106.camel@mhfsdcap03> References: <1559527086-7227-1-git-send-email-biao.huang@mediatek.com> <1559527086-7227-4-git-send-email-biao.huang@mediatek.com> <78EB27739596EE489E55E81C33FEC33A0B93B6DF@DE02WEMBXB.internal.synopsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <78EB27739596EE489E55E81C33FEC33A0B93B6DF@DE02WEMBXB.internal.synopsys.com> Sender: linux-kernel-owner@vger.kernel.org To: Jose Abreu Cc: "davem@davemloft.net" , "andrew@lunn.ch" , Giuseppe Cavallaro , Alexandre Torgue , Maxime Coquelin , Matthias Brugger , "netdev@vger.kernel.org" , "linux-stm32@st-md-mailman.stormreply.com" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "linux-mediatek@lists.infradead.org" , "yt.shen@mediatek.com" , "jianguo.zhang@mediatek.com" , "boon.leong.ong@intel.com" List-Id: linux-mediatek@lists.infradead.org On Mon, 2019-06-03 at 11:40 +0000, Jose Abreu wrote: > From: Biao Huang > > > the default value of tx-frames is 25, it's too late when > > passing tstamp to stack, then the ptp4l will fail: > > > > ptp4l -i eth0 -f gPTP.cfg -m > > ptp4l: selected /dev/ptp0 as PTP clock > > ptp4l: port 1: INITIALIZING to LISTENING on INITIALIZE > > ptp4l: port 0: INITIALIZING to LISTENING on INITIALIZE > > ptp4l: port 1: link up > > ptp4l: timed out while polling for tx timestamp > > ptp4l: increasing tx_timestamp_timeout may correct this issue, > > but it is likely caused by a driver bug > > ptp4l: port 1: send peer delay response failed > > ptp4l: port 1: LISTENING to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED) > > > > ptp4l tests pass when changing the tx-frames from 25 to 1 with > > ethtool -C option. > > It should be fine to set tx-frames default value to 1, so ptp4l will pass > > by default. > > I'm not sure if this is the right approach ... What's the timeout value > you have for TX Timestamp ? I use the default tx_timestamp_timeout value 1, which represents 1ms. do you try ptp4l on your side? performance test is done in https://lkml.org/lkml/2019/5/30/1617 and seems no performance degradation. > > Thanks, > Jose Miguel Abreu From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, T_DKIMWL_WL_HIGH,UNPARSEABLE_RELAY,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B4596C04AB5 for ; Tue, 4 Jun 2019 02:31:32 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8C03E25773 for ; Tue, 4 Jun 2019 02:31:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="KIMcg4G4" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8C03E25773 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=tvyg7uIRBytxYJigaHJ0Vp0g1h5GJLLyH7d72xchd+Y=; b=KIMcg4G4r/tnM+ xeDFMrSs3+7Uj0rEFt/z7rRYEw26K00Lci06WqOf66y4AkpkGDDGVhuepPgIlxgIEybkV0iQg5aM6 mlDAI7VAd7HUoJCBuyWd4mEu3aQI8m5dbjKI6TNrJqOhpvcfhThb3htIYz9ItS5CMCLo/lli+SZ/p HP13JhnlAsCn5jiLJDGUwSnhcc6O/EEqf2SOfxJ6oK8iRzVK7PhJolzt6svuB4KFN/BhZdKm4Ba53 +RQRVIXLwrKMy/XDuJxr0RQb0blAKdnIzLHHsq7ob954omwFAP2pIZ4OqymGQCQ/jfMEZ/YgI90Gp AQorhOpUPo4UE3+c2kjg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hXzEV-0001cN-1Z; Tue, 04 Jun 2019 02:31:27 +0000 Received: from mailgw01.mediatek.com ([216.200.240.184]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hXzER-0001R9-Pw; Tue, 04 Jun 2019 02:31:25 +0000 X-UUID: ee0d5ad1c587492499dd69305bf88f47-20190603 X-UUID: ee0d5ad1c587492499dd69305bf88f47-20190603 Received: from mtkcas68.mediatek.inc [(172.29.94.19)] by mailgw01.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLS) with ESMTP id 633810019; Mon, 03 Jun 2019 18:31:10 -0800 Received: from MTKMBS31DR.mediatek.inc (172.27.6.102) by MTKMBS62DR.mediatek.inc (172.29.94.18) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 3 Jun 2019 19:31:09 -0700 Received: from MTKCAS32.mediatek.inc (172.27.4.184) by MTKMBS31DR.mediatek.inc (172.27.6.102) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 4 Jun 2019 10:31:06 +0800 Received: from [10.17.3.153] (172.27.4.253) by MTKCAS32.mediatek.inc (172.27.4.170) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Tue, 4 Jun 2019 10:31:06 +0800 Message-ID: <1559615466.24897.106.camel@mhfsdcap03> Subject: RE: [v2, PATCH 3/4] net: stmmac: modify default value of tx-frames From: biao huang To: Jose Abreu Date: Tue, 4 Jun 2019 10:31:06 +0800 In-Reply-To: <78EB27739596EE489E55E81C33FEC33A0B93B6DF@DE02WEMBXB.internal.synopsys.com> References: <1559527086-7227-1-git-send-email-biao.huang@mediatek.com> <1559527086-7227-4-git-send-email-biao.huang@mediatek.com> <78EB27739596EE489E55E81C33FEC33A0B93B6DF@DE02WEMBXB.internal.synopsys.com> X-Mailer: Evolution 3.2.3-0ubuntu6 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190603_193123_855250_6027AEEF X-CRM114-Status: GOOD ( 13.67 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "andrew@lunn.ch" , "jianguo.zhang@mediatek.com" , Alexandre Torgue , "boon.leong.ong@intel.com" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-stm32@st-md-mailman.stormreply.com" , "yt.shen@mediatek.com" , "linux-mediatek@lists.infradead.org" , Maxime Coquelin , Matthias Brugger , Giuseppe Cavallaro , "davem@davemloft.net" , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, 2019-06-03 at 11:40 +0000, Jose Abreu wrote: > From: Biao Huang > > > the default value of tx-frames is 25, it's too late when > > passing tstamp to stack, then the ptp4l will fail: > > > > ptp4l -i eth0 -f gPTP.cfg -m > > ptp4l: selected /dev/ptp0 as PTP clock > > ptp4l: port 1: INITIALIZING to LISTENING on INITIALIZE > > ptp4l: port 0: INITIALIZING to LISTENING on INITIALIZE > > ptp4l: port 1: link up > > ptp4l: timed out while polling for tx timestamp > > ptp4l: increasing tx_timestamp_timeout may correct this issue, > > but it is likely caused by a driver bug > > ptp4l: port 1: send peer delay response failed > > ptp4l: port 1: LISTENING to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED) > > > > ptp4l tests pass when changing the tx-frames from 25 to 1 with > > ethtool -C option. > > It should be fine to set tx-frames default value to 1, so ptp4l will pass > > by default. > > I'm not sure if this is the right approach ... What's the timeout value > you have for TX Timestamp ? I use the default tx_timestamp_timeout value 1, which represents 1ms. do you try ptp4l on your side? performance test is done in https://lkml.org/lkml/2019/5/30/1617 and seems no performance degradation. > > Thanks, > Jose Miguel Abreu _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel