All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Tobias Waldekranz <tobias@waldekranz.com>
Cc: "David S . Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	netdev@vger.kernel.org, Florian Fainelli <f.fainelli@gmail.com>,
	Andrew Lunn <andrew@lunn.ch>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Kurt Kanzenbach <kurt@linutronix.de>,
	Woojung Huh <woojung.huh@microchip.com>,
	UNGLinuxDriver@microchip.com, Sean Wang <sean.wang@mediatek.com>,
	Landen Chao <Landen.Chao@mediatek.com>,
	Claudiu Manoil <claudiu.manoil@nxp.com>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	George McCollister <george.mccollister@gmail.com>,
	DENG Qingfang <dqfext@gmail.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Hauke Mehrtens <hauke@hauke-m.de>,
	Rasmus Villemoes <rasmus.villemoes@prevas.dk>,
	Oleksij Rempel <linux@rempel-privat.de>
Subject: Re: [PATCH net-next 4/4] net: dsa: don't set skb->offload_fwd_mark when not offloading the bridge
Date: Fri, 26 Feb 2021 20:14:30 +0200	[thread overview]
Message-ID: <20210226181430.5q3olzmozpqpl2fm@skbuf> (raw)
In-Reply-To: <875z2grluk.fsf@waldekranz.com>

On Thu, Feb 25, 2021 at 08:25:23PM +0100, Tobias Waldekranz wrote:
> On Sun, Feb 14, 2021 at 17:53, Vladimir Oltean <olteanv@gmail.com> wrote:
> > From: Vladimir Oltean <vladimir.oltean@nxp.com>
> >
> > DSA has gained the recent ability to deal gracefully with upper
> > interfaces it cannot offload, such as the bridge, bonding or team
> > drivers. When such uppers exist, the ports are still in standalone mode
> > as far as the hardware is concerned.
> >
> > But when we deliver packets to the software bridge in order for that to
> > do the forwarding, there is an unpleasant surprise in that the bridge
> > will refuse to forward them. This is because we unconditionally set
> > skb->offload_fwd_mark = true, meaning that the bridge thinks the frames
> > were already forwarded in hardware by us.
> >
> > Since dp->bridge_dev is populated only when there is hardware offload
> > for it, but not in the software fallback case, let's introduce a new
> > helper that can be called from the tagger data path which sets the
> > skb->offload_fwd_mark accordingly to zero when there is no hardware
> > offload for bridging. This lets the bridge forward packets back to other
> > interfaces of our switch, if needed.
> >
> > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> > ---
> 
> For the generic and tag_dsa.c related changes:
> 
> Reviewed-by: Tobias Waldekranz <tobias@waldekranz.com>

Actually with my switchdev_bridge_port_offload_notify() proposal, I
don't think this patch is going to be needed at all. I think the bridge
happily ignores a packet with skb->offload_fwd_mark = 1 if it comes from
a port which has an offload_fwd_mark of 0, although I haven't tested that.

  reply	other threads:[~2021-02-26 18:15 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-14 15:53 [PATCH net-next 0/4] Software fallback for bridging in DSA Vladimir Oltean
2021-02-14 15:53 ` [PATCH net-next 1/4] net: dsa: don't offload switchdev objects on ports that don't offload the bridge Vladimir Oltean
2021-02-25 19:23   ` Tobias Waldekranz
2021-02-14 15:53 ` [PATCH net-next 2/4] net: dsa: reject switchdev objects centrally from dsa_slave_port_obj_{add,del} Vladimir Oltean
2021-02-25 19:24   ` Tobias Waldekranz
2021-02-14 15:53 ` [PATCH net-next 3/4] net: dsa: return -EOPNOTSUPP if .port_lag_join is not implemented Vladimir Oltean
2021-02-25 19:24   ` Tobias Waldekranz
2021-02-14 15:53 ` [PATCH net-next 4/4] net: dsa: don't set skb->offload_fwd_mark when not offloading the bridge Vladimir Oltean
2021-02-15 15:48   ` George McCollister
2021-02-15 17:19     ` Vladimir Oltean
2021-02-25 19:25   ` Tobias Waldekranz
2021-02-26 18:14     ` Vladimir Oltean [this message]
2021-02-14 16:28 ` [PATCH net-next 0/4] Software fallback for bridging in DSA Vladimir Oltean

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=20210226181430.5q3olzmozpqpl2fm@skbuf \
    --to=olteanv@gmail.com \
    --cc=Landen.Chao@mediatek.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=andrew@lunn.ch \
    --cc=claudiu.manoil@nxp.com \
    --cc=davem@davemloft.net \
    --cc=dqfext@gmail.com \
    --cc=f.fainelli@gmail.com \
    --cc=george.mccollister@gmail.com \
    --cc=hauke@hauke-m.de \
    --cc=kuba@kernel.org \
    --cc=kurt@linutronix.de \
    --cc=linus.walleij@linaro.org \
    --cc=linux@rempel-privat.de \
    --cc=netdev@vger.kernel.org \
    --cc=rasmus.villemoes@prevas.dk \
    --cc=sean.wang@mediatek.com \
    --cc=tobias@waldekranz.com \
    --cc=vivien.didelot@gmail.com \
    --cc=woojung.huh@microchip.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.