netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Tobias Waldekranz <tobias@waldekranz.com>
Cc: davem@davemloft.net, kuba@kernel.org, vivien.didelot@gmail.com,
	f.fainelli@gmail.com, olteanv@gmail.com, netdev@vger.kernel.org
Subject: Re: [PATCH v2 net-next 1/2] net: dsa: tag_dsa: Unify regular and ethertype DSA taggers
Date: Sat, 14 Nov 2020 16:44:56 +0100	[thread overview]
Message-ID: <20201114154456.GY1480543@lunn.ch> (raw)
In-Reply-To: <C72Y9Y96O02K.2J4BFT8MY7S6U@wkz-x280>

> > > + *
> > > + * A 3-bit code is used to relay why a particular frame was sent to
> > > + * the CPU. We only use this to determine if the packet was mirrored
> > > + * or trapped, i.e. whether the packet has been forwarded by hardware
> > > + * or not.
> >
> > Maybe add that, not all generations support all codes.
> 
> Not sure I have that information.

I'm not asking you list per code which switches support it. I'm just
think we should add a warning, it cannot be assumed all switches
support all codes. I just looked at the 6161 for example, and it is
missing 5 from its list.

> > > +			 */
> > > +			return NULL;
> > > +		case DSA_CODE_ARP_MIRROR:
> > > +		case DSA_CODE_POLICY_MIRROR:
> > > +			/* Mark mirrored packets to notify any upper
> > > +			 * device (like a bridge) that forwarding has
> > > +			 * already been done by hardware.
> > > +			 */
> > > +			skb->offload_fwd_mark = 1;
> > > +			break;
> > > +		case DSA_CODE_MGMT_TRAP:
> > > +		case DSA_CODE_IGMP_MLD_TRAP:
> > > +		case DSA_CODE_POLICY_TRAP:
> > > +			/* Traps have, by definition, not been
> > > +			 * forwarded by hardware, so don't mark them.
> > > +			 */
> >
> > Humm, yes, they have not been forwarded by hardware. But is the
> > software bridge going to do the right thing and not flood them? Up
> 
> The bridge is free to flood them if it wants to (e.g. IGMP/MLD
> snooping is off) or not (e.g. IGMP/MLD snooping enabled). The point
> is, that is not for a lowly switchdev driver to decide. Our job is to
> relay to the bridge if this skb has been forwarded or not, the end.
> 
> > until now, i think we did mark them. So this is a clear change in
> > behaviour. I wonder if we want to break this out into a separate
> > patch? If something breaks, we can then bisect was it the combining
> > which broke it, or the change of this mark.
> 
> Since mv88e6xxx can not configure anything that generates
> DSA_CODE_MGMT_TRAP or DSA_CODE_POLICY_TRAP yet, we do not have to
> worry about any change in behavior there.
> 
> That leaves us with DSA_CODE_IGMP_MLD_TRAP. Here is the problem:
> 
> Currenly, tag_dsa.c will set skb->offload_fwd_mark for IGMP/MLD
> packets, whereas tag_edsa.c will exempt them. So we can not unify the
> two without changing the behavior of one.

I'm not saying that this change is wrong. I'm just afraid as a
behaviour change, it might break something. If something does break,
it will be easier to track down, if it is a change on its own. So
please look if we can add a simple patch to tag_dsa.c which removes
the marking of such frames. And then the next patch can combine the
two into one driver. If it does break, git bisect will then tell us
which patch broke it.

     Andrew

  parent reply	other threads:[~2020-11-14 15:45 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-11 13:11 [PATCH v2 net-next 0/2] net: dsa: tag_dsa: Unify regular and ethertype DSA taggers Tobias Waldekranz
2020-11-11 13:11 ` [PATCH v2 net-next 1/2] " Tobias Waldekranz
2020-11-14  0:27   ` Jakub Kicinski
2020-11-14  0:56     ` Vladimir Oltean
2020-11-14  1:03   ` Vladimir Oltean
2020-11-14  2:08   ` Andrew Lunn
2020-11-14 11:29     ` Tobias Waldekranz
2020-11-14 12:20       ` Vladimir Oltean
2020-11-14 12:36         ` Tobias Waldekranz
2020-11-14 15:44       ` Andrew Lunn [this message]
2020-11-14 19:55         ` Tobias Waldekranz
2020-11-11 13:11 ` [PATCH v2 net-next 2/2] net: dsa: tag_dsa: Use a consistent comment style Tobias Waldekranz
2020-11-14  1:04   ` Vladimir Oltean
2020-11-14  2:10   ` 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=20201114154456.GY1480543@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=tobias@waldekranz.com \
    --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).