mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Felix Fietkau <nbd@nbd.name>
Cc: netdev@vger.kernel.org, John Crispin <john@phrozen.org>,
	Sean Wang <sean.wang@mediatek.com>,
	Mark Lee <Mark-MC.Lee@mediatek.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
	Jiri Pirko <jiri@nvidia.com>, Ido Schimmel <idosch@nvidia.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Vladimir Oltean <vladimir.oltean@nxp.com>
Subject: Re: [PATCH v2 14/14] net: ethernet: mtk_eth_soc: support creating mac address based offload entries
Date: Tue, 12 Apr 2022 15:07:24 +0200	[thread overview]
Message-ID: <YlV5jEzNZT1aKmNL@lunn.ch> (raw)
In-Reply-To: <ece29b0d-bbbe-7c03-a6b4-60e44453ca31@nbd.name>

> > > > > I'm trying to understand the architecture here.
> > > > > We have an Ethernet interface and a Wireless interface. The slow
> > > path
> > > > is that frames ingress from one of these interfaces, Linux decides
> > > > what to do with them, either L2 or L3, and they then egress probably
> > > > out the other interface.
> > > > > The hardware will look at the frames and try to spot flows? It
> > > will
> > > > then report any it finds. You can then add an offload, telling it for
> > > > a flow it needs to perform L2 or L3 processing, and egress out a
> > > > specific port? Linux then no longer sees the frame, the hardware
> > > > handles it, until the flow times out?
> > > Yes, the hw handles it until either the flow times out, or the corresponding
> > > offload entry is removed.
> > > 
> > > For OpenWrt I also wrote a daemon that uses tc classifier BPF to accelerate
> > > the software bridge and create hardware offload entries as well via hardware
> > > TC flower rules: https://github.com/nbd168/bridger
> > > It works in combination with these changes.
> > 
> > What about the bridge? In Linux, it is the software bridge which
> > controls all this at L2, and it should be offloading the flows, via
> > switchdev. The egress port you derive here is from the software bridge
> > FDB?

> My code uses netlink to fetch and monitor the bridge configuration,
> including fdb, port state, vlans, etc. and it uses that for the offload path
> - no extra configuration needed.

So this is where we get into architecture issues. Do we really want
Linux to have two ways for setting up L2 networking? It was decided
that users should not need to know about how to use an accelerator,
they should not use additional tools, it should just look like
linux. The user should just add the WiFi netdev to the bridge and
switchdev will do the rest to offload L2 switching to the hardware.

You appear to be saying you need a daemon in userspace. That is not
how every other accelerate works in Linux networking.

We the Linux network community need to decided if we want this?

    Andrew

  reply	other threads:[~2022-04-12 13:18 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20220405195755.10817-1-nbd@nbd.name>
2022-04-05 19:57 ` [PATCH v2 01/14] dt-bindings: net: mediatek: add optional properties for the SoC ethernet core Felix Fietkau
2022-04-07 17:20   ` Rob Herring
2022-04-08  9:34     ` Lorenzo Bianconi
2022-04-05 19:57 ` [PATCH v2 02/14] net: ethernet: mtk_eth_soc: add support for coherent DMA Felix Fietkau
2022-04-05 19:57 ` [PATCH v2 03/14] arm64: dts: mediatek: mt7622: " Felix Fietkau
2022-04-05 19:57 ` [PATCH v2 04/14] dt-bindings: arm: mediatek: document WED binding for MT7622 Felix Fietkau
2022-04-06  8:09   ` Krzysztof Kozlowski
2022-04-06  8:18     ` Felix Fietkau
2022-04-06  8:29       ` Arnd Bergmann
2022-04-06  8:32         ` Felix Fietkau
2022-04-06  8:57           ` Krzysztof Kozlowski
2022-04-07 16:59             ` Felix Fietkau
2022-04-07 15:50       ` Andrew Lunn
2022-04-07 16:10         ` Felix Fietkau
2022-04-05 19:57 ` [PATCH v2 05/14] dt-bindings: arm: mediatek: document the pcie mirror node on MT7622 Felix Fietkau
2022-04-06  8:20   ` Krzysztof Kozlowski
2022-04-06 11:01     ` Felix Fietkau
2022-04-07 17:16       ` Rob Herring
2022-04-07 17:29         ` Felix Fietkau
2022-04-07 17:19   ` Rob Herring
2022-04-08  9:03     ` Felix Fietkau
2022-04-05 19:57 ` [PATCH v2 06/14] net: ethernet: mtk_eth_soc: add support for Wireless Ethernet Dispatch (WED) Felix Fietkau
2022-04-05 19:57 ` [PATCH v2 07/14] net: ethernet: mtk_eth_soc: implement flow offloading to WED devices Felix Fietkau
2022-04-05 19:57 ` [PATCH v2 08/14] arm64: dts: mediatek: mt7622: introduce nodes for Wireless Ethernet Dispatch Felix Fietkau
2022-04-05 19:57 ` [PATCH v2 09/14] net: ethernet: mtk_eth_soc: add ipv6 flow offload support Felix Fietkau
2022-04-05 19:57 ` [PATCH v2 10/14] net: ethernet: mtk_eth_soc: support TC_SETUP_BLOCK for PPE offload Felix Fietkau
2022-04-05 19:57 ` [PATCH v2 11/14] net: ethernet: mtk_eth_soc: allocate struct mtk_ppe separately Felix Fietkau
2022-04-05 19:57 ` [PATCH v2 12/14] net: ethernet: mtk_eth_soc: rework hardware flow table management Felix Fietkau
2022-04-05 19:57 ` [PATCH v2 13/14] net: ethernet: mtk_eth_soc: remove bridge flow offload type entry support Felix Fietkau
2022-04-05 19:57 ` [PATCH v2 14/14] net: ethernet: mtk_eth_soc: support creating mac address based offload entries Felix Fietkau
2022-04-07 18:10   ` Andrew Lunn
2022-04-07 18:21     ` Felix Fietkau
2022-04-11 13:00       ` Andrew Lunn
2022-04-12  7:13         ` Felix Fietkau
2022-04-12 13:07           ` Andrew Lunn [this message]
2022-04-12 13:49             ` Felix Fietkau
2022-04-12 14:21               ` Andrew Lunn
2022-04-12 15:51                 ` Felix Fietkau
2022-04-12 17:37                   ` Andrew Lunn
2022-04-12 17:51                     ` Felix Fietkau

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=YlV5jEzNZT1aKmNL@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=Mark-MC.Lee@mediatek.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=idosch@nvidia.com \
    --cc=jiri@nvidia.com \
    --cc=john@phrozen.org \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=nbd@nbd.name \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sean.wang@mediatek.com \
    --cc=vladimir.oltean@nxp.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

all inboxes | Powered by JetHome®