From: Ido Schimmel <idosch@nvidia.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Ido Schimmel <idosch@mellanox.com>,
Vladimir Oltean <vladimir.oltean@nxp.com>,
Nikolay Aleksandrov <razor@blackwall.org>,
"bridge@lists.linux-foundation.org"
<bridge@lists.linux-foundation.org>,
netdev <netdev@vger.kernel.org>
Subject: Re: [Bridge] [PATCH RFC] net: bridge: Clear offload_fwd_mark when passing frame up bridge interface.
Date: Fri, 13 May 2022 15:47:20 +0300 [thread overview]
Message-ID: <Yn5TWIZPBVLFipVD@shredder> (raw)
In-Reply-To: <Yn1wK78zKzcgzg15@lunn.ch>
On Thu, May 12, 2022 at 10:38:03PM +0200, Andrew Lunn wrote:
> > I like Andrew's patch because it is the Rx equivalent of
> > br_switchdev_frame_unmark() in br_dev_xmit(). However, if we go with the
> > second option, it should allow us to remove the clearing of the mark in
> > the Tx path as the control block is cleared in the Tx path since commit
> > fd65e5a95d08 ("net: bridge: clear bridge's private skb space on xmit").
> >
> > I don't know how far back Nik's patch was backported and I don't know
> > how far back Andrew's patch will be backported, so it might be best to
> > submit Andrew's patch to net as-is and then in net-next change
> > nbp_switchdev_allowed_egress() and remove br_switchdev_frame_unmark()
> > from both the Rx and Tx paths.
> >
> > Anyway, I have applied this patch to our tree for testing. Will report
> > tomorrow in case there are any regressions.
>
> Hi Ido
>
> Did your testing find any issues?
No, patch is fine. Thanks!
WARNING: multiple messages have this Message-ID (diff)
From: Ido Schimmel <idosch@nvidia.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>,
netdev <netdev@vger.kernel.org>,
Nikolay Aleksandrov <razor@blackwall.org>,
Ido Schimmel <idosch@mellanox.com>,
"bridge@lists.linux-foundation.org"
<bridge@lists.linux-foundation.org>
Subject: Re: [PATCH RFC] net: bridge: Clear offload_fwd_mark when passing frame up bridge interface.
Date: Fri, 13 May 2022 15:47:20 +0300 [thread overview]
Message-ID: <Yn5TWIZPBVLFipVD@shredder> (raw)
In-Reply-To: <Yn1wK78zKzcgzg15@lunn.ch>
On Thu, May 12, 2022 at 10:38:03PM +0200, Andrew Lunn wrote:
> > I like Andrew's patch because it is the Rx equivalent of
> > br_switchdev_frame_unmark() in br_dev_xmit(). However, if we go with the
> > second option, it should allow us to remove the clearing of the mark in
> > the Tx path as the control block is cleared in the Tx path since commit
> > fd65e5a95d08 ("net: bridge: clear bridge's private skb space on xmit").
> >
> > I don't know how far back Nik's patch was backported and I don't know
> > how far back Andrew's patch will be backported, so it might be best to
> > submit Andrew's patch to net as-is and then in net-next change
> > nbp_switchdev_allowed_egress() and remove br_switchdev_frame_unmark()
> > from both the Rx and Tx paths.
> >
> > Anyway, I have applied this patch to our tree for testing. Will report
> > tomorrow in case there are any regressions.
>
> Hi Ido
>
> Did your testing find any issues?
No, patch is fine. Thanks!
next prev parent reply other threads:[~2022-05-13 12:47 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-05 22:59 [Bridge] [PATCH RFC] net: bridge: Clear offload_fwd_mark when passing frame up bridge interface Andrew Lunn
2022-05-05 22:59 ` Andrew Lunn
2022-05-05 23:07 ` [Bridge] " Stephen Hemminger
2022-05-05 23:07 ` Stephen Hemminger
2022-05-06 1:18 ` [Bridge] " Andrew Lunn
2022-05-06 1:18 ` Andrew Lunn
2022-05-06 15:05 ` [Bridge] " Stephen Hemminger
2022-05-06 15:05 ` Stephen Hemminger
2022-05-06 14:36 ` [Bridge] " Vladimir Oltean
2022-05-06 14:36 ` Vladimir Oltean
2022-05-06 16:58 ` [Bridge] " Andrew Lunn
2022-05-06 16:58 ` Andrew Lunn
2022-05-08 7:52 ` [Bridge] " Ido Schimmel
2022-05-08 7:52 ` Ido Schimmel
2022-05-12 20:38 ` [Bridge] " Andrew Lunn
2022-05-12 20:38 ` Andrew Lunn
2022-05-13 12:47 ` Ido Schimmel [this message]
2022-05-13 12:47 ` Ido Schimmel
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=Yn5TWIZPBVLFipVD@shredder \
--to=idosch@nvidia.com \
--cc=andrew@lunn.ch \
--cc=bridge@lists.linux-foundation.org \
--cc=idosch@mellanox.com \
--cc=netdev@vger.kernel.org \
--cc=razor@blackwall.org \
--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 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.