netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Daniel Mack <daniel@zonque.org>
Cc: Jason Cobham <jcobham@questertangent.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Ido Schimmel <idosch@idosch.org>, Jiri Pirko <jiri@resnulli.us>,
	Ivan Vecera <ivecera@redhat.com>,
	Florian Fainelli <f.fainelli@gmail.com>
Subject: Re: Question on DSA switches, IGMP forwarding and switchdev
Date: Sat, 20 Jun 2020 16:35:18 +0200	[thread overview]
Message-ID: <20200620143518.GG304147@lunn.ch> (raw)
In-Reply-To: <eb6b5f84-2a5a-1938-0657-0eac9f2390df@zonque.org>

> So yes, we can read the code here, but I'm wondering which packet types
> would then get this flag set, and which won't. Because in case of
> IGMP/MLD, the packets are in fact forwarded, but the meaning of the flag
> in skb is to prevent the skb from being forwarded further, which seems
> wrong in all cases.
> 
> I'm thinking maybe the flag should never be set?

It is a while since i did much with multicast, so please correct me
when i'm wrong...

IGMP can use different group addresses as far as i remember.
Join/leave uses the group address of interest. But query can use
224.0.0.1 or the group address.

The bridge should learn from joins, either spontaneous or as a reply
to a query. When it sees a join, it should add a multicast FDB to the
hardware for the group, so traffic is forwarded out that port.

So for real multicast traffic, we do want the flag set, the hardware
should be doing the forwarding. If we don't set the flag, we end up
with duplication when the SW bridge also forwards the multicast
traffic.

For IGMP/MLD itself, we probably need to see what the switch does. For
IGMP using the group address, does the multicast FDB rule match and
cause the hardware to forward the IGMP? If yes, then we need the flag
set, otherwise the IGMP gets duplicated. If no, then we don't want the
flag set, and leave the SW bridge to do the forwarding, or reply
itself if it is the querier.

For IGMP using 224.0.0.1, do we ever get a multicast FDB added for
that?

It sounds like you have a better test setup than i have. Can you play
with this?

6352 uses the EDSA tagger. But the same bits exist in the DSA tag,
which the 6390 uses, due to incompatibility reasons. So it would be
nice to extend both taggers.

     Thanks
	Andrew

  reply	other threads:[~2020-06-20 14:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-19 21:31 Question on DSA switches, IGMP forwarding and switchdev Daniel Mack
2020-06-19 21:58 ` Andrew Lunn
2020-06-19 22:05   ` Jason Cobham
2020-06-19 22:36     ` Andrew Lunn
2020-06-20  6:02       ` Daniel Mack
2020-06-20 14:35         ` Andrew Lunn [this message]
2020-06-20 18:01           ` Daniel Mack
2020-06-20  5:32   ` Daniel Mack

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=20200620143518.GG304147@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=daniel@zonque.org \
    --cc=f.fainelli@gmail.com \
    --cc=idosch@idosch.org \
    --cc=ivecera@redhat.com \
    --cc=jcobham@questertangent.com \
    --cc=jiri@resnulli.us \
    --cc=netdev@vger.kernel.org \
    /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).