netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Guilherme G. Piccoli" <gpiccoli@canonical.com>
To: Sudarsana Reddy Kalluru <skalluru@marvell.com>
Cc: GR-everest-linux-l2 <GR-everest-linux-l2@marvell.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Ariel Elior <aelior@marvell.com>,
	"jay.vosburgh@canonical.com" <jay.vosburgh@canonical.com>
Subject: Re: [EXT] [PATCH V3] bnx2x: Prevent ptp_task to be rescheduled indefinitely
Date: Thu, 27 Jun 2019 13:20:25 -0300	[thread overview]
Message-ID: <4aaa2e33-5847-88e8-ff73-d30aca8d4872@canonical.com> (raw)
In-Reply-To: <MN2PR18MB2528E0CB660FC35C475816E1D3FD0@MN2PR18MB2528.namprd18.prod.outlook.com>

Thanks again Sudarsana for the good review and advice. I'll send V4 soon.
Discussions about your points are in-line below:


On 27/06/2019 07:09, Sudarsana Reddy Kalluru wrote:
> 
>> [...]
>>  	if (unlikely(skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP)) {
>>  		if (!(bp->flags & TX_TIMESTAMPING_EN)) {
>> -			BNX2X_ERR("Tx timestamping was not enabled, this
>> packet will not be timestamped\n");
>> +			bp->eth_stats.ptp_skip_tx_ts++;
>> +			netdev_err_once(bp->dev,
>> +					"Tx timestamping isn't enabled, this
>> packet won't be timestamped\n");
>> +			DP(BNX2X_MSG_PTP,
>> +			   "Tx timestamping isn't enabled, this packet won't
>> be
>> +timestamped\n");
> 
> Hitting this path is very unlikely and also PTP packets arrive once in a second in general.
> Either retain BNX2X_ERR() statement or remove the extra call netdev_err_once().

Agreed, I retained BNX2X_ERR().


> 
>>  		} else if (bp->ptp_tx_skb) {
>> -			BNX2X_ERR("The device supports only a single
>> outstanding packet to timestamp, this packet will not be timestamped\n");
>> +			bp->eth_stats.ptp_skip_tx_ts++;
>> +			netdev_err_once(bp->dev,
>> +					"Device supports only a single
>> outstanding packet to timestamp, this packet won't be timestamped\n");
>> +			DP(BNX2X_MSG_PTP,
>> +			   "Device supports only a single outstanding packet to
>> timestamp,
>> +this packet won't be timestamped\n");
> Same as above.

Now this one I disagree - it's easy to have kernel log flooded by these
messages if, for instance, you reproduce the bug I'm trying to fix.
Even with my patch, the register value is 0x0 in TX timestamping read,
so this is likely to keep showing in the kernel, and may cause a
somewhat quick log rotation depending on user configuration.

For this one, I've removed the debug statement, but kept netdev_err_once
to warn users that something is wrong without slowly flood their logs.
If the users want more detail, they just need to enable debug level
logging in bnx2x. Makes sense to you?


>>  		} else {
>>  			skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
>>  			/* schedule check for Tx timestamp */ diff --git
>> a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
>> b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
>> index 51fc845de31a..4a0ba6801c9e 100644
>> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
>> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
>> @@ -182,7 +182,9 @@ static const struct {
>>  	{ STATS_OFFSET32(driver_filtered_tx_pkt),
>>  				4, false, "driver_filtered_tx_pkt" },
>>  	{ STATS_OFFSET32(eee_tx_lpi),
>> -				4, true, "Tx LPI entry count"}
>> +				4, true, "Tx LPI entry count"},
>> +	{ STATS_OFFSET32(ptp_skip_tx_ts),
>> +				4, false, "ptp_skipped_tx_tstamp" },
>>  };
>>
>>  #define BNX2X_NUM_STATS		ARRAY_SIZE(bnx2x_stats_arr)
>> diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
>> b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
>> index 03ac10b1cd1e..af6e7a950a28 100644
>> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
>> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
>> @@ -15214,11 +15214,27 @@ static void bnx2x_ptp_task(struct work_struct
>> *work)
>>  	u32 val_seq;
>>  	u64 timestamp, ns;
>>  	struct skb_shared_hwtstamps shhwtstamps;
>> +	bool bail = true;
>> +	int i;
>>
>> -	/* Read Tx timestamp registers */
>> -	val_seq = REG_RD(bp, port ? NIG_REG_P1_TLLH_PTP_BUF_SEQID :
>> -			 NIG_REG_P0_TLLH_PTP_BUF_SEQID);
>> -	if (val_seq & 0x10000) {
>> +	/* FW may take a while to complete timestamping; try a bit and if it's
>> +	 * still not complete, may indicate an error state - bail out then.
>> +	 */
>> +	for (i = 0; i < 10; i++) {
>> +		/* Read Tx timestamp registers */
>> +		val_seq = REG_RD(bp, port ?
>> NIG_REG_P1_TLLH_PTP_BUF_SEQID :
>> +				 NIG_REG_P0_TLLH_PTP_BUF_SEQID);
>> +		if (val_seq & 0x10000) {
>> +			bail = false;
>> +			break;
>> +		}
>> +
>> +		if (!(i % 4)) /* Avoid log flood */
>> +			DP(BNX2X_MSG_PTP, "There's no valid Tx timestamp
>> yet\n");
> This debug statement is not required as we anyway capture it in the error path below.
> 

Ack, removed.


>> +		msleep(1 << i);
>> +	}
>> +
>> +	if (!bail) {
>>  		/* There is a valid timestamp value */
>>  		timestamp = REG_RD(bp, port ?
>> NIG_REG_P1_TLLH_PTP_BUF_TS_MSB :
>>  				   NIG_REG_P0_TLLH_PTP_BUF_TS_MSB);
>> @@ -15233,16 +15249,18 @@ static void bnx2x_ptp_task(struct work_struct
>> *work)
>>  		memset(&shhwtstamps, 0, sizeof(shhwtstamps));
>>  		shhwtstamps.hwtstamp = ns_to_ktime(ns);
>>  		skb_tstamp_tx(bp->ptp_tx_skb, &shhwtstamps);
>> -		dev_kfree_skb_any(bp->ptp_tx_skb);
>> -		bp->ptp_tx_skb = NULL;
>>
>>  		DP(BNX2X_MSG_PTP, "Tx timestamp, timestamp cycles =
>> %llu, ns = %llu\n",
>>  		   timestamp, ns);
>>  	} else {
>> -		DP(BNX2X_MSG_PTP, "There is no valid Tx timestamp
>> yet\n");
>> -		/* Reschedule to keep checking for a valid timestamp value
>> */
>> -		schedule_work(&bp->ptp_task);
>> +		DP(BNX2X_MSG_PTP,
>> +		   "Tx timestamp is not recorded (register read=%u)\n",
>> +		   val_seq);
>> +		bp->eth_stats.ptp_skip_tx_ts++;
>>  	}
>> +
>> +	dev_kfree_skb_any(bp->ptp_tx_skb);
>> +	bp->ptp_tx_skb = NULL;
>>  }
>>
>>  void bnx2x_set_rx_ts(struct bnx2x *bp, struct sk_buff *skb) diff --git
>> a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.h
>> b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.h
>> index b2644ed13d06..d55e63692cf3 100644
>> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.h
>> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.h
>> @@ -207,6 +207,9 @@ struct bnx2x_eth_stats {
>>  	u32 driver_filtered_tx_pkt;
>>  	/* src: Clear-on-Read register; Will not survive PMF Migration */
>>  	u32 eee_tx_lpi;
>> +
>> +	/* PTP */
>> +	u32 ptp_skip_tx_ts;
> The value need to be cleared in the case of internal reload e.g., mtu change, ifconfig-down/up.
> If this is not happening, please reset it in the nic load path.

I mostly agree with you here. The stat really needs to be zeroed in
interface reload, and it is, currently.
The path doing this on driver is:

bnx2x_nic_load()
  bnx2x_post_irq_nic_init()
    bnx2x_stats_init()

I've tested that using "ifconfig <iface> down" and then up. The
"ptp_skip_tx_ts" was zeroed. But for example, in MTU change it kept its
value, which I consider right. We don't want a MTU change to clear
stats, in my understanding.
The driver is behaving right IMO, what governs the reset of statistics
is "bp->stats_init", which is set in bnx2x_open(), leading to full stats
reset.

I've checked and the behavior is the same for other statistics like
rx_bytes (both per-queue and accumulated) and tx_*_packets.
If you consider this behavior as wrong we can fix that in another patch,
or if you think for some reason "ptp_skip_tx_ts" should behave
differently from the other statistics, let me know.

Thanks,

Guilherme


> 
>>  };
>>
>>  struct bnx2x_eth_q_stats {
>> --
>> 2.22.0
> 

      reply	other threads:[~2019-06-27 16:20 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-26 20:18 [PATCH V3] bnx2x: Prevent ptp_task to be rescheduled indefinitely Guilherme G. Piccoli
2019-06-27 10:09 ` [EXT] " Sudarsana Reddy Kalluru
2019-06-27 16:20   ` Guilherme G. Piccoli [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4aaa2e33-5847-88e8-ff73-d30aca8d4872@canonical.com \
    --to=gpiccoli@canonical.com \
    --cc=GR-everest-linux-l2@marvell.com \
    --cc=aelior@marvell.com \
    --cc=jay.vosburgh@canonical.com \
    --cc=netdev@vger.kernel.org \
    --cc=skalluru@marvell.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).