On Wed, Jun 26, 2019 at 5:25 AM Sudarsana Reddy Kalluru
<skall...@marvell.com> wrote:
> > Sudarsana, let me ask you something: why does the register is reading value
> > 0x0 always in the TX timestamp routine if the RX filter is set to None?
> > This is
> > the main cause of the thread reschedule thing.
>
> The register value of zero indicates there is no pending Tx timestamp to be
> read by the driver.
> FW writes/latches the Tx timestamp for PTP event packet in this register. And
> it does the latching only if the register is free.
> In this case user/app look to be requesting the Timestamp (via
> skb->tx_flags) for non-ptp Tx packet. In the Tx path, driver schedules a
> thread for reading the Tx timestamp,
> bnx2x_start_xmit()
> {
> if (unlikely(skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP))
> schedule_work(&bp->ptp_task);
> }
> FW seem to be not timestamping the packet at all and driver is indefinitely
> waiting for it.
>
Thanks Sudarsana! I've tried to implement the qede-like approach
again, with the 2s timeout before
bailing-out the thread reschedule. This time, I've remove _all_log
messages, including the DP() ones...
Unfortunately kthread is still consuming 100% of CPU, which makes
sense, since it reschedules itself
the most times it can in this 2s window...I think we really should
have small pauses before retrying to
read the registers. I've worked a V3, implementing 1ms-starting
pauses, which worked well:
https://marc.info/?l=linux-netdev&m=156158032618932
I hope this way we don't harm the PTP applications, nor introduce
delays in the FW wait-queue,
and at same time we can fix the indefinitely reschedule in bnx2x.
Thanks again for your support,
Guilherme
