netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Eichenberger <stefan.eichenberger@netmodule.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Stefan Eichenberger <eichest@gmail.com>,
	<vivien.didelot@savoirfairelinux.com>, <f.fainelli@gmail.com>,
	<netdev@vger.kernel.org>
Subject: Re: [PATCH] net: dsa: mv88e6xxx: egress all frames
Date: Tue, 22 Nov 2016 19:37:33 +0100	[thread overview]
Message-ID: <20161122183732.GD13973@gruene.netmodule.intranet> (raw)
In-Reply-To: <20161122150330.GE2691@lunn.ch>

Hi Andrew

On Tue, Nov 22, 2016 at 04:03:30PM +0100, Andrew Lunn wrote:
> On Tue, Nov 22, 2016 at 11:39:44AM +0100, Stefan Eichenberger wrote:
> > Egress multicast and egress unicast is only enabled for CPU/DSA ports
> > but for switching operation it seems it should be enabled for all ports.
> > Do I miss something here?
> > 
> > I did the following test:
> > brctl addbr br0
> > brctl addif br0 lan0
> > brctl addif br0 lan1
> > 
> > In this scenario the unicast and multicast packets were not forwarded,
> > therefore ARP requests were not resolved, and no connection could be
> > established.
> 
> Hi Stefan
> 
> This is probably specific to the 6097 family. It works fine without
> this on other devices. Creating a bridge like above and pinging across
> it is one of my standard tests. But i only test modern devices like
> the 6165, 6352, 6351, 6390 families.

Okay perfect, I wasn't 100% sure if I would have to configure something
additionally.

> 
> In fact, you might need to review all the code and look where
> mv88e6xxx_6095_family(chip) is used and consider if you need to add
> mv88e6xxx_6097_family(chip). e.g.
> 
>         if (mv88e6xxx_6095_family(chip) || mv88e6xxx_6185_family(chip)) {
>                 /* Set the upstream port this port should use */
>                 reg |= dsa_upstream_port(ds);
>                 /* enable forwarding of unknown multicast addresses to
>                  * the upstream port
>                  */
>                 if (port == dsa_upstream_port(ds))
>                         reg |= PORT_CONTROL_2_FORWARD_UNKNOWN;
>         }
> 
> Maybe this is your problem?

I think I still don't understand exactly how the driver works.

My problem is that the multicast and broadcast frames are filtered and
the following counter is increasing in ethtool:
sw_in_filtered: 596

This makes sense because "Egress Floods" in the Port Control Register is
set to 0. What kind of mechanism should make sure that for example ARP
packets are sent trough all ports anyway?

Unfortunately I don't have any devices available with more modern
devices, so I can't double check the registers.

Regards,
Stefan

  reply	other threads:[~2016-11-22 18:52 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-22 10:39 [PATCH] net: dsa: mv88e6xxx: egress all frames Stefan Eichenberger
2016-11-22 15:03 ` Andrew Lunn
2016-11-22 18:37   ` Stefan Eichenberger [this message]
2016-11-22 19:02     ` Andrew Lunn
2016-11-22 22:15       ` Vivien Didelot
2016-11-23  9:56         ` Stefan Eichenberger
2016-11-23 12:00       ` Stefan Eichenberger
2016-11-23 15:59         ` Vivien Didelot
2016-11-23 16:50           ` Stefan Eichenberger
2016-11-23 16:54             ` [PATCH v2] net: dsa: mv88e6xxx: forward unknown mc packets on mv88e6097 Stefan Eichenberger
2016-11-23 16:59               ` Andrew Lunn
2016-11-23 17:11                 ` [PATCH v3] net: dsa: mv88e6xxx: enable EDSA " Stefan Eichenberger
2016-11-23 17:13                   ` Andrew Lunn
2016-11-23 17:14                 ` [PATCH v2] net: dsa: mv88e6xxx: forward unknown mc packets " Stefan Eichenberger
2016-11-23 17:32                   ` Andrew Lunn
2016-11-23 17:49                     ` Stefan Eichenberger
2016-11-23 17:40                   ` Andrew Lunn
2016-11-23 17:52                     ` Vivien Didelot
2016-11-23 18:01                       ` Andrew Lunn
2016-11-23 18:18                         ` Vivien Didelot
2016-11-23 16:58             ` [PATCH] net: dsa: mv88e6xxx: egress all frames 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=20161122183732.GD13973@gruene.netmodule.intranet \
    --to=stefan.eichenberger@netmodule.com \
    --cc=andrew@lunn.ch \
    --cc=eichest@gmail.com \
    --cc=f.fainelli@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=vivien.didelot@savoirfairelinux.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).