From: Simon Horman <horms@kernel.org>
To: Gerhard Engleder <gerhard@engleder-embedded.com>
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
linux-pci@vger.kernel.org, anthony.l.nguyen@intel.com,
przemyslaw.kitszel@intel.com, andrew+netdev@lunn.ch,
davem@davemloft.net, kuba@kernel.org, edumazet@google.com,
pabeni@redhat.com, bhelgaas@google.com, pmenzel@molgen.mpg.de,
aleksander.lobakin@intel.com, Gerhard Engleder <eg@keba.com>,
Vitaly Lifshits <vitaly.lifshits@intel.com>,
Avigail Dahan <avigailx.dahan@intel.com>
Subject: Re: [Intel-wired-lan] [PATCH iwl-next v4] e1000e: Fix real-time violations on link up
Date: Mon, 6 Jan 2025 11:17:52 +0000 [thread overview]
Message-ID: <20250106111752.GC4068@kernel.org> (raw)
In-Reply-To: <20241219192743.4499-1-gerhard@engleder-embedded.com>
On Thu, Dec 19, 2024 at 08:27:43PM +0100, Gerhard Engleder wrote:
> From: Gerhard Engleder <eg@keba.com>
>
> Link down and up triggers update of MTA table. This update executes many
> PCIe writes and a final flush. Thus, PCIe will be blocked until all
> writes are flushed. As a result, DMA transfers of other targets suffer
> from delay in the range of 50us. This results in timing violations on
> real-time systems during link down and up of e1000e in combination with
> an Intel i3-2310E Sandy Bridge CPU.
>
> The i3-2310E is quite old. Launched 2011 by Intel but still in use as
> robot controller. The exact root cause of the problem is unclear and
> this situation won't change as Intel support for this CPU has ended
> years ago. Our experience is that the number of posted PCIe writes needs
> to be limited at least for real-time systems. With posted PCIe writes a
> much higher throughput can be generated than with PCIe reads which
> cannot be posted. Thus, the load on the interconnect is much higher.
> Additionally, a PCIe read waits until all posted PCIe writes are done.
> Therefore, the PCIe read can block the CPU for much more than 10us if a
> lot of PCIe writes were posted before. Both issues are the reason why we
> are limiting the number of posted PCIe writes in row in general for our
> real-time systems, not only for this driver.
>
> A flush after a low enough number of posted PCIe writes eliminates the
> delay but also increases the time needed for MTA table update. The
> following measurements were done on i3-2310E with e1000e for 128 MTA
> table entries:
>
> Single flush after all writes: 106us
> Flush after every write: 429us
> Flush after every 2nd write: 266us
> Flush after every 4th write: 180us
> Flush after every 8th write: 141us
> Flush after every 16th write: 121us
>
> A flush after every 8th write delays the link up by 35us and the
> negative impact to DMA transfers of other targets is still tolerable.
>
> Execute a flush after every 8th write. This prevents overloading the
> interconnect with posted writes.
>
> Signed-off-by: Gerhard Engleder <eg@keba.com>
> Link: https://lore.kernel.org/netdev/f8fe665a-5e6c-4f95-b47a-2f3281aa0e6c@lunn.ch/T/
> CC: Vitaly Lifshits <vitaly.lifshits@intel.com>
> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
> Tested-by: Avigail Dahan <avigailx.dahan@intel.com>
> ---
> v4:
> - add PREEMPT_RT dependency again (Vitaly Lifshits)
> - fix comment styple (Alexander Lobakin)
> - add to comment each 8th and explain why (Alexander Lobakin)
> - simplify check for every 8th write (Alexander Lobakin)
>
> v3:
> - mention problematic platform explicitly (Bjorn Helgaas)
> - improve comment (Paul Menzel)
>
> v2:
> - remove PREEMPT_RT dependency (Andrew Lunn, Przemek Kitszel)
Reviewed-by: Simon Horman <horms@kernel.org>
WARNING: multiple messages have this Message-ID (diff)
From: Simon Horman <horms@kernel.org>
To: Gerhard Engleder <gerhard@engleder-embedded.com>
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
linux-pci@vger.kernel.org, anthony.l.nguyen@intel.com,
przemyslaw.kitszel@intel.com, andrew+netdev@lunn.ch,
davem@davemloft.net, kuba@kernel.org, edumazet@google.com,
pabeni@redhat.com, bhelgaas@google.com, pmenzel@molgen.mpg.de,
aleksander.lobakin@intel.com, Gerhard Engleder <eg@keba.com>,
Vitaly Lifshits <vitaly.lifshits@intel.com>,
Avigail Dahan <avigailx.dahan@intel.com>
Subject: Re: [PATCH iwl-next v4] e1000e: Fix real-time violations on link up
Date: Mon, 6 Jan 2025 11:17:52 +0000 [thread overview]
Message-ID: <20250106111752.GC4068@kernel.org> (raw)
In-Reply-To: <20241219192743.4499-1-gerhard@engleder-embedded.com>
On Thu, Dec 19, 2024 at 08:27:43PM +0100, Gerhard Engleder wrote:
> From: Gerhard Engleder <eg@keba.com>
>
> Link down and up triggers update of MTA table. This update executes many
> PCIe writes and a final flush. Thus, PCIe will be blocked until all
> writes are flushed. As a result, DMA transfers of other targets suffer
> from delay in the range of 50us. This results in timing violations on
> real-time systems during link down and up of e1000e in combination with
> an Intel i3-2310E Sandy Bridge CPU.
>
> The i3-2310E is quite old. Launched 2011 by Intel but still in use as
> robot controller. The exact root cause of the problem is unclear and
> this situation won't change as Intel support for this CPU has ended
> years ago. Our experience is that the number of posted PCIe writes needs
> to be limited at least for real-time systems. With posted PCIe writes a
> much higher throughput can be generated than with PCIe reads which
> cannot be posted. Thus, the load on the interconnect is much higher.
> Additionally, a PCIe read waits until all posted PCIe writes are done.
> Therefore, the PCIe read can block the CPU for much more than 10us if a
> lot of PCIe writes were posted before. Both issues are the reason why we
> are limiting the number of posted PCIe writes in row in general for our
> real-time systems, not only for this driver.
>
> A flush after a low enough number of posted PCIe writes eliminates the
> delay but also increases the time needed for MTA table update. The
> following measurements were done on i3-2310E with e1000e for 128 MTA
> table entries:
>
> Single flush after all writes: 106us
> Flush after every write: 429us
> Flush after every 2nd write: 266us
> Flush after every 4th write: 180us
> Flush after every 8th write: 141us
> Flush after every 16th write: 121us
>
> A flush after every 8th write delays the link up by 35us and the
> negative impact to DMA transfers of other targets is still tolerable.
>
> Execute a flush after every 8th write. This prevents overloading the
> interconnect with posted writes.
>
> Signed-off-by: Gerhard Engleder <eg@keba.com>
> Link: https://lore.kernel.org/netdev/f8fe665a-5e6c-4f95-b47a-2f3281aa0e6c@lunn.ch/T/
> CC: Vitaly Lifshits <vitaly.lifshits@intel.com>
> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
> Tested-by: Avigail Dahan <avigailx.dahan@intel.com>
> ---
> v4:
> - add PREEMPT_RT dependency again (Vitaly Lifshits)
> - fix comment styple (Alexander Lobakin)
> - add to comment each 8th and explain why (Alexander Lobakin)
> - simplify check for every 8th write (Alexander Lobakin)
>
> v3:
> - mention problematic platform explicitly (Bjorn Helgaas)
> - improve comment (Paul Menzel)
>
> v2:
> - remove PREEMPT_RT dependency (Andrew Lunn, Przemek Kitszel)
Reviewed-by: Simon Horman <horms@kernel.org>
next prev parent reply other threads:[~2025-01-06 11:18 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-19 19:27 [Intel-wired-lan] [PATCH iwl-next v4] e1000e: Fix real-time violations on link up Gerhard Engleder
2024-12-19 19:27 ` Gerhard Engleder
2024-12-22 8:49 ` [Intel-wired-lan] " Lifshits, Vitaly
2024-12-22 8:49 ` Lifshits, Vitaly
2025-01-06 11:17 ` Simon Horman [this message]
2025-01-06 11:17 ` Simon Horman
2025-02-04 20:18 ` [Intel-wired-lan] " Gerhard Engleder
2025-02-04 20:18 ` Gerhard Engleder
2025-02-04 21:21 ` [Intel-wired-lan] " Tony Nguyen
2025-02-04 21:21 ` Tony Nguyen
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=20250106111752.GC4068@kernel.org \
--to=horms@kernel.org \
--cc=aleksander.lobakin@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=avigailx.dahan@intel.com \
--cc=bhelgaas@google.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eg@keba.com \
--cc=gerhard@engleder-embedded.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=kuba@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pmenzel@molgen.mpg.de \
--cc=przemyslaw.kitszel@intel.com \
--cc=vitaly.lifshits@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.