From: Andrew Lunn <andrew@lunn.ch>
To: Robert Beckett <bob.beckett@collabora.com>
Cc: Ido Schimmel <idosch@mellanox.com>,
Florian Fainelli <f.fainelli@gmail.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Vivien Didelot <vivien.didelot@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Jiri Pirko <jiri@resnulli.us>
Subject: Re: [PATCH 0/7] net: dsa: mv88e6xxx: features to handle network storms
Date: Thu, 12 Sep 2019 00:58:41 +0200 [thread overview]
Message-ID: <20190911225841.GB5710@lunn.ch> (raw)
In-Reply-To: <3f50ee51ec04a2d683a5338a68607824a3f45711.camel@collabora.com>
> We have a setup as follows:
>
> Marvell 88E6240 switch chip, accepting traffic from 4 ports. Port 1
> (P1) is critical priority, no dropped packets allowed, all others can
> be best effort.
>
> CPU port of swtich chip is connected via phy to phy of intel i210 (igb
> driver).
>
> i210 is connected via pcie switch to imx6.
>
> When too many small packets attempt to be delivered to CPU port (e.g.
> during broadcast flood) we saw dropped packets.
>
> The packets were being received by i210 in to rx descriptor buffer
> fine, but the CPU could not keep up with the load. We saw
> rx_fifo_errors increasing rapidly and ksoftirqd at ~100% CPU.
>
>
> With this in mind, I am wondering whether any amount of tc traffic
> shaping would help?
Hi Robert
The model in linux is that you start with a software TC filter, and
then offload it to the hardware. So the user configures TC just as
normal, and then that is used to program the hardware to do the same
thing as what would happen in software. This is exactly the same as we
do with bridging. You create a software bridge and add interfaces to
the bridge. This then gets offloaded to the hardware and it does the
bridging for you.
So think about how your can model the Marvell switch capabilities
using TC, and implement offload support for it.
Andrew
next prev parent reply other threads:[~2019-09-11 22:59 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-10 15:41 [PATCH 0/7] net: dsa: mv88e6xxx: features to handle network storms Robert Beckett
2019-09-10 15:41 ` [PATCH 1/7] net/dsa: configure autoneg for CPU port Robert Beckett
2019-09-10 16:14 ` Vivien Didelot
2019-09-10 16:56 ` Florian Fainelli
2019-09-10 18:26 ` Andrew Lunn
2019-09-10 18:29 ` Florian Fainelli
2019-09-11 9:16 ` Robert Beckett
2019-09-11 9:54 ` Robert Beckett
2019-09-11 22:52 ` Andrew Lunn
2019-09-12 10:14 ` Robert Beckett
2019-09-12 10:43 ` Andrew Lunn
2019-09-11 11:43 ` kbuild test robot
2019-09-14 7:16 ` kbuild test robot
2019-09-10 15:41 ` [PATCH 2/7] net: dsa: mv88e6xxx: add ability to set default queue priorities per port Robert Beckett
2019-09-10 16:43 ` Vivien Didelot
2019-09-10 15:41 ` [PATCH 3/7] dt-bindings: " Robert Beckett
2019-09-10 16:42 ` Florian Fainelli
2019-09-10 16:49 ` Vivien Didelot
2019-09-10 20:46 ` Vladimir Oltean
2019-09-10 15:41 ` [PATCH 4/7] net: dsa: mv88e6xxx: add ability to set queue scheduling Robert Beckett
2019-09-10 17:18 ` Vivien Didelot
2019-09-10 15:41 ` [PATCH 5/7] dt-bindings: " Robert Beckett
2019-09-10 15:41 ` [PATCH 6/7] net: dsa: mv88e6xxx: add egress rate limiting Robert Beckett
2019-09-10 17:13 ` Vivien Didelot
2019-09-11 12:26 ` kbuild test robot
2019-09-10 15:41 ` [PATCH 7/7] dt-bindings: " Robert Beckett
2019-09-10 16:49 ` [PATCH 0/7] net: dsa: mv88e6xxx: features to handle network storms Florian Fainelli
2019-09-11 9:43 ` Robert Beckett
2019-09-11 11:21 ` Ido Schimmel
2019-09-11 11:49 ` Robert Beckett
2019-09-11 22:58 ` Andrew Lunn [this message]
2019-09-12 9:05 ` Ido Schimmel
2019-09-12 9:03 ` Ido Schimmel
2019-09-12 9:21 ` Andrew Lunn
2019-09-12 16:25 ` Florian Fainelli
2019-09-12 16:46 ` Robert Beckett
2019-09-12 17:41 ` Florian Fainelli
2019-09-13 12:47 ` Robert Beckett
2019-09-10 17:19 ` Vivien Didelot
2019-09-11 9:46 ` Robert Beckett
2019-09-11 15:31 ` Vivien Didelot
2019-09-11 23:01 ` Andrew Lunn
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=20190911225841.GB5710@lunn.ch \
--to=andrew@lunn.ch \
--cc=bob.beckett@collabora.com \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=idosch@mellanox.com \
--cc=jiri@resnulli.us \
--cc=netdev@vger.kernel.org \
--cc=vivien.didelot@gmail.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).