netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Kurt Kanzenbach <kurt@linutronix.de>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	netdev@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
	devicetree@vger.kernel.org,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Richard Cochran <richardcochran@gmail.com>,
	Kamil Alkhouri <kamil.alkhouri@hs-offenburg.de>,
	ilias.apalodimas@linaro.org,
	Vladimir Oltean <vladimir.oltean@nxp.com>
Subject: Re: [PATCH net-next v7 2/8] net: dsa: Give drivers the chance to veto certain upper devices
Date: Thu, 29 Oct 2020 01:05:31 +0100	[thread overview]
Message-ID: <20201029000531.GD933237@lunn.ch> (raw)
In-Reply-To: <20201028104344.56exyeh5tbwefyw5@skbuf>

On Wed, Oct 28, 2020 at 12:43:44PM +0200, Vladimir Oltean wrote:
> On Wed, Oct 28, 2020 at 08:42:15AM +0100, Kurt Kanzenbach wrote:
> > From: Vladimir Oltean <vladimir.oltean@nxp.com>
> > 
> > Some switches rely on unique pvids to ensure port separation in
> > standalone mode, because they don't have a port forwarding matrix
> > configurable in hardware. So, setups like a group of 2 uppers with the
> > same VLAN, swp0.100 and swp1.100, will cause traffic tagged with VLAN
> > 100 to be autonomously forwarded between these switch ports, in spite
> > of there being no bridge between swp0 and swp1.
> > 
> > These drivers need to prevent this from happening. They need to have
> > VLAN filtering enabled in standalone mode (so they'll drop frames tagged
> > with unknown VLANs) and they can only accept an 8021q upper on a port as
> > long as it isn't installed on any other port too. So give them the
> > chance to veto bad user requests.
> > 
> > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> > Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de>
> > ---
> 
> In case reviewers have doubts about this new DSA operation in general.
> I would expect that when LAG support is merged, some drivers will
> support it, but not any tx_type, but e.g. just NETDEV_LAG_TX_TYPE_HASH.
> So it would also be helpful in that case, so they could veto other types
> of bond interfaces cleanly. So I do see the need for a generic
> "prechangeupper" operation given to drivers.

There is always the interesting question, do we want to veto, or
simply not accelerate it? We will want to consider that case by case.

       Andrew

  reply	other threads:[~2020-10-29  0:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-28  7:42 [PATCH net-next v7 0/8] Hirschmann Hellcreek DSA driver Kurt Kanzenbach
2020-10-28  7:42 ` [PATCH net-next v7 1/8] net: dsa: Add tag handling for Hirschmann Hellcreek switches Kurt Kanzenbach
2020-10-28  7:42 ` [PATCH net-next v7 2/8] net: dsa: Give drivers the chance to veto certain upper devices Kurt Kanzenbach
2020-10-28 10:43   ` Vladimir Oltean
2020-10-29  0:05     ` Andrew Lunn [this message]
2020-10-29  2:22   ` Florian Fainelli
2020-10-28  7:42 ` [PATCH net-next v7 3/8] net: dsa: Add DSA driver for Hirschmann Hellcreek switches Kurt Kanzenbach
2020-10-28 10:29   ` Vladimir Oltean
2020-10-29  2:29   ` Florian Fainelli
2020-10-28  7:42 ` [PATCH net-next v7 4/8] net: dsa: hellcreek: Add PTP clock support Kurt Kanzenbach
2020-10-28  7:42 ` [PATCH net-next v7 5/8] net: dsa: hellcreek: Add support for hardware timestamping Kurt Kanzenbach
2020-10-28  7:42 ` [PATCH net-next v7 6/8] net: dsa: hellcreek: Add PTP status LEDs Kurt Kanzenbach
2020-10-28  7:42 ` [PATCH net-next v7 7/8] dt-bindings: Add vendor prefix for Hirschmann Kurt Kanzenbach
2020-10-28  7:42 ` [PATCH net-next v7 8/8] dt-bindings: net: dsa: Add documentation for Hellcreek switches Kurt Kanzenbach
2020-10-29 15:26   ` Rob Herring

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=20201029000531.GD933237@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=bigeasy@linutronix.de \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=kamil.alkhouri@hs-offenburg.de \
    --cc=kuba@kernel.org \
    --cc=kurt@linutronix.de \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=richardcochran@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=vivien.didelot@gmail.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;
as well as URLs for NNTP newsgroup(s).