From: Gerhard Engleder <gerhard@engleder-embedded.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: netdev@vger.kernel.org, davem@davemloft.net, kuba@kernel.org,
edumazet@google.com, pabeni@redhat.com
Subject: Re: [PATCH net-next 2/4] tsnep: Fix rotten packets
Date: Fri, 18 Nov 2022 07:13:34 +0100 [thread overview]
Message-ID: <5fefbc3d-c83b-d628-e660-15abfa596b1b@engleder-embedded.com> (raw)
In-Reply-To: <Y3ab7xim0EfyCQHm@lunn.ch>
On 17.11.22 21:39, Andrew Lunn wrote:
> On Thu, Nov 17, 2022 at 09:14:38PM +0100, Gerhard Engleder wrote:
>> If PTP synchronisation is done every second, then sporadic the interval
>> is higher than one second:
>>
>> ptp4l[696.582]: master offset -17 s2 freq -1891 path delay 573
>> ptp4l[697.582]: master offset -22 s2 freq -1901 path delay 573
>> ptp4l[699.368]: master offset -1 s2 freq -1887 path delay 573
>> ^^^^^^^ Should be 698.582!
>>
>> This problem is caused by rotten packets, which are received after
>> polling but before interrupts are enabled again.
>
> Is this a hardware bug? At the end of the interrupt coalescence
> period, should it not check the queue and fire an interrupt?
In my case, the hardware is not signaled if a descriptor is processed by
the software. The hardware is only signaled if it gets new descriptors
assigned. So the hardware does not know if there are still descriptors
in the RX queue which need to be processed by the software. As a result,
it would only be possible to trigger an interrupt for descriptors which
may has been processed already anyway.
In the end I made the hardware stupid. If interrupts are disabled for
NAPI polling, then interrupts events in the hardware are ignored. If
interrupts are enabled again, then only new interrupt events will
trigger the interrupt. I was afraid that too intelligent hardware will
lead to hardware bugs in this case.
Gerhard
next prev parent reply other threads:[~2022-11-18 6:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-17 20:14 [PATCH net-next 0/4] tsnep: Throttle irq, rotten pkts, RX buffer alloc and ethtool_get_channels() Gerhard Engleder
2022-11-17 20:14 ` [PATCH net-next 1/4] tsnep: Throttle interrupts Gerhard Engleder
2022-11-17 20:33 ` Andrew Lunn
2022-11-18 5:50 ` Gerhard Engleder
2022-11-19 1:24 ` Jakub Kicinski
2022-11-19 20:46 ` Gerhard Engleder
2022-11-17 20:14 ` [PATCH net-next 2/4] tsnep: Fix rotten packets Gerhard Engleder
2022-11-17 20:39 ` Andrew Lunn
2022-11-18 6:13 ` Gerhard Engleder [this message]
2022-11-19 1:26 ` Jakub Kicinski
2022-11-19 20:47 ` Gerhard Engleder
2022-11-17 20:14 ` [PATCH net-next 3/4] tsnep: Add ethtool get_channels support Gerhard Engleder
2022-11-17 20:14 ` [PATCH net-next 4/4] tsnep: Rework RX buffer allocation Gerhard Engleder
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=5fefbc3d-c83b-d628-e660-15abfa596b1b@engleder-embedded.com \
--to=gerhard@engleder-embedded.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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).