All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans Schultz <schultz.hans@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>, Hans Schultz <schultz.hans@gmail.com>
Cc: Ivan Vecera <ivecera@redhat.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Jiri Pirko <jiri@resnulli.us>,
	Daniel Borkmann <daniel@iogearbox.net>,
	netdev@vger.kernel.org, Nikolay Aleksandrov <razor@blackwall.org>,
	bridge@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Ido Schimmel <idosch@nvidia.com>, Roopa Prabhu <roopa@nvidia.com>,
	kuba@kernel.org, Vladimir Oltean <olteanv@gmail.com>,
	davem@davemloft.net
Subject: Re: [Bridge] [PATCH net-next 3/3] net: dsa: mv88e6xxx: mac-auth/MAB implementation
Date: Fri, 11 Mar 2022 08:59:04 +0100	[thread overview]
Message-ID: <86y21gvs1j.fsf@gmail.com> (raw)
In-Reply-To: <YioRQpUTJ7WmTLXQ@lunn.ch>

On tor, mar 10, 2022 at 15:54, Andrew Lunn <andrew@lunn.ch> wrote:
>> +		if (mv88e6xxx_port_is_locked(chip, chip->ports[spid].port))
>> +			err = mv88e6xxx_switchdev_handle_atu_miss_violation(chip,
>> +									    chip->ports[spid].port,
>> +									    &entry,
>> +									    fid);
>
>> +static int mv88e6xxx_find_vid_on_matching_fid(struct mv88e6xxx_chip *chip,
>> +					      const struct mv88e6xxx_vtu_entry *entry,
>> +					      void *priv)
>> +{
>> +	struct mv88e6xxx_fid_search_ctx *ctx = priv;
>> +
>> +	if (ctx->fid_search == entry->fid) {
>> +		ctx->vid_found = entry->vid;
>> +		return 1;
>> +	}
>> +	return 0;
>> +}
>> +
>> +int mv88e6xxx_switchdev_handle_atu_miss_violation(struct mv88e6xxx_chip *chip,
>> +						  int port,
>> +						  struct mv88e6xxx_atu_entry *entry,
>> +						  u16 fid)
>> +{
>> +	struct switchdev_notifier_fdb_info info = {
>> +		.addr = entry->mac,
>> +		.vid = 0,
>> +		.added_by_user = false,
>> +		.is_local = false,
>> +		.offloaded = true,
>> +		.locked = true,
>> +	};
>> +	struct mv88e6xxx_fid_search_ctx ctx;
>> +	struct netlink_ext_ack *extack;
>> +	struct net_device *brport;
>> +	struct dsa_port *dp;
>> +	int err;
>> +
>> +	ctx.fid_search = fid;
>> +	err = mv88e6xxx_vtu_walk(chip, mv88e6xxx_find_vid_on_matching_fid, &ctx);
>
> I could be reading this code wrong, but it looks like you assume there
> is a single new entry in the ATU. But interrupts on these devices are
> slow. It would be easy for two or more devices to pop into existence
> at the same time. Don't you need to walk the whole ATU to find all the
> new entries? Have you tried this with a traffic generating populating
> the ATU with new entries at different rates, up to line rate? Do you
> get notifications for them all?
>
>     Andrew

We have not tried your said test, but if a packet doesn't manage to
trigger a ATU miss violation interrupt, not much will happen as far as I
see. The device sending the packet will not get access, but if it sends
again (maybe after a short while), it can still trigger the ATU miss
violation interrupt and get access.
I think that the normal behaviour for a device would be to try and
connect, and if that is not successfull inside a short time, it will wait
for a timeout before trying again.

WARNING: multiple messages have this Message-ID (diff)
From: Hans Schultz <schultz.hans@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>, Hans Schultz <schultz.hans@gmail.com>
Cc: davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Vladimir Oltean <olteanv@gmail.com>,
	Jiri Pirko <jiri@resnulli.us>, Ivan Vecera <ivecera@redhat.com>,
	Roopa Prabhu <roopa@nvidia.com>,
	Nikolay Aleksandrov <razor@blackwall.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Ido Schimmel <idosch@nvidia.com>,
	linux-kernel@vger.kernel.org, bridge@lists.linux-foundation.org
Subject: Re: [PATCH net-next 3/3] net: dsa: mv88e6xxx: mac-auth/MAB implementation
Date: Fri, 11 Mar 2022 08:59:04 +0100	[thread overview]
Message-ID: <86y21gvs1j.fsf@gmail.com> (raw)
In-Reply-To: <YioRQpUTJ7WmTLXQ@lunn.ch>

On tor, mar 10, 2022 at 15:54, Andrew Lunn <andrew@lunn.ch> wrote:
>> +		if (mv88e6xxx_port_is_locked(chip, chip->ports[spid].port))
>> +			err = mv88e6xxx_switchdev_handle_atu_miss_violation(chip,
>> +									    chip->ports[spid].port,
>> +									    &entry,
>> +									    fid);
>
>> +static int mv88e6xxx_find_vid_on_matching_fid(struct mv88e6xxx_chip *chip,
>> +					      const struct mv88e6xxx_vtu_entry *entry,
>> +					      void *priv)
>> +{
>> +	struct mv88e6xxx_fid_search_ctx *ctx = priv;
>> +
>> +	if (ctx->fid_search == entry->fid) {
>> +		ctx->vid_found = entry->vid;
>> +		return 1;
>> +	}
>> +	return 0;
>> +}
>> +
>> +int mv88e6xxx_switchdev_handle_atu_miss_violation(struct mv88e6xxx_chip *chip,
>> +						  int port,
>> +						  struct mv88e6xxx_atu_entry *entry,
>> +						  u16 fid)
>> +{
>> +	struct switchdev_notifier_fdb_info info = {
>> +		.addr = entry->mac,
>> +		.vid = 0,
>> +		.added_by_user = false,
>> +		.is_local = false,
>> +		.offloaded = true,
>> +		.locked = true,
>> +	};
>> +	struct mv88e6xxx_fid_search_ctx ctx;
>> +	struct netlink_ext_ack *extack;
>> +	struct net_device *brport;
>> +	struct dsa_port *dp;
>> +	int err;
>> +
>> +	ctx.fid_search = fid;
>> +	err = mv88e6xxx_vtu_walk(chip, mv88e6xxx_find_vid_on_matching_fid, &ctx);
>
> I could be reading this code wrong, but it looks like you assume there
> is a single new entry in the ATU. But interrupts on these devices are
> slow. It would be easy for two or more devices to pop into existence
> at the same time. Don't you need to walk the whole ATU to find all the
> new entries? Have you tried this with a traffic generating populating
> the ATU with new entries at different rates, up to line rate? Do you
> get notifications for them all?
>
>     Andrew

We have not tried your said test, but if a packet doesn't manage to
trigger a ATU miss violation interrupt, not much will happen as far as I
see. The device sending the packet will not get access, but if it sends
again (maybe after a short while), it can still trigger the ATU miss
violation interrupt and get access.
I think that the normal behaviour for a device would be to try and
connect, and if that is not successfull inside a short time, it will wait
for a timeout before trying again.

  reply	other threads:[~2022-03-11  7:59 UTC|newest]

Thread overview: 106+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-10 14:23 [Bridge] [PATCH net-next 0/3] Extend locked port feature with FDB locked flag (MAC-Auth/MAB) Hans Schultz
2022-03-10 14:23 ` Hans Schultz
2022-03-10 14:23 ` [Bridge] [PATCH net-next 1/3] net: bridge: add fdb flag to extent locked port feature Hans Schultz
2022-03-10 14:23   ` Hans Schultz
2022-03-10 14:42   ` [Bridge] " Nikolay Aleksandrov
2022-03-10 14:42     ` Nikolay Aleksandrov
2022-03-10 15:38     ` [Bridge] " Hans Schultz
2022-03-10 15:38       ` Hans Schultz
2022-03-10 15:57       ` [Bridge] " Nikolay Aleksandrov
2022-03-10 15:57         ` Nikolay Aleksandrov
2022-03-10 16:11         ` [Bridge] " Hans Schultz
2022-03-10 16:11           ` Hans Schultz
2022-03-10 16:14           ` [Bridge] " Nikolay Aleksandrov
2022-03-10 16:14             ` Nikolay Aleksandrov
2022-03-10 16:33             ` [Bridge] " Hans Schultz
2022-03-10 16:33               ` Hans Schultz
2022-03-14 15:30   ` [Bridge] " Ido Schimmel
2022-03-14 15:30     ` Ido Schimmel
2022-03-15  8:48     ` [Bridge] " Hans Schultz
2022-03-15  8:48       ` Hans Schultz
2022-03-15 11:00       ` [Bridge] " Ido Schimmel
2022-03-15 11:00         ` Ido Schimmel
2022-03-10 14:23 ` [Bridge] [PATCH net-next 2/3] net: switchdev: add support for offloading of fdb locked flag Hans Schultz
2022-03-10 14:23   ` Hans Schultz
2022-03-10 14:23 ` [Bridge] [PATCH net-next 3/3] net: dsa: mv88e6xxx: mac-auth/MAB implementation Hans Schultz
2022-03-10 14:23   ` Hans Schultz
2022-03-10 14:28   ` [Bridge] " Vladimir Oltean
2022-03-10 14:28     ` Vladimir Oltean
2022-03-10 15:00     ` [Bridge] " Hans Schultz
2022-03-10 15:00       ` Hans Schultz
2022-03-10 15:07       ` [Bridge] " Vladimir Oltean
2022-03-10 15:07         ` Vladimir Oltean
2022-03-10 15:51         ` [Bridge] " Hans Schultz
2022-03-10 15:51           ` Hans Schultz
2022-03-10 16:05           ` [Bridge] " Vladimir Oltean
2022-03-10 16:05             ` Vladimir Oltean
2022-03-10 16:40             ` [Bridge] " Hans Schultz
2022-03-10 16:40               ` Hans Schultz
2022-03-10 15:57     ` [Bridge] " Hans Schultz
2022-03-10 15:57       ` Hans Schultz
2022-03-14 10:46     ` [Bridge] " Hans Schultz
2022-03-14 10:46       ` Hans Schultz
2022-03-16 23:34       ` [Bridge] " Vladimir Oltean
2022-03-16 23:34         ` Vladimir Oltean
2022-03-17  8:52         ` [Bridge] " Hans Schultz
2022-03-17  8:52           ` Hans Schultz
2022-03-17 14:19           ` [Bridge] " Andrew Lunn
2022-03-17 14:19             ` Andrew Lunn
2022-03-17 15:36             ` [Bridge] " Vladimir Oltean
2022-03-17 15:36               ` Vladimir Oltean
2022-03-17 16:07               ` [Bridge] " Hans Schultz
2022-03-17 16:07                 ` Hans Schultz
2022-03-17 16:18                 ` [Bridge] " Vladimir Oltean
2022-03-17 16:18                   ` Vladimir Oltean
2022-03-17 16:58                   ` [Bridge] " Hans Schultz
2022-03-17 16:58                     ` Hans Schultz
2022-03-17 17:20                     ` [Bridge] " Vladimir Oltean
2022-03-17 17:20                       ` Vladimir Oltean
2022-03-18 10:04                       ` [Bridge] " Hans Schultz
2022-03-18 10:04                         ` Hans Schultz
2022-03-18 12:14                         ` [Bridge] " Vladimir Oltean
2022-03-18 12:14                           ` Vladimir Oltean
2022-03-18 13:10                           ` [Bridge] " Hans Schultz
2022-03-18 13:10                             ` Hans Schultz
2022-03-18 13:19                             ` [Bridge] " Vladimir Oltean
2022-03-18 13:19                               ` Vladimir Oltean
2022-03-22 11:01                               ` [Bridge] " Hans Schultz
2022-03-22 11:01                                 ` Hans Schultz
2022-03-22 11:08                                 ` [Bridge] " Vladimir Oltean
2022-03-22 11:08                                   ` Vladimir Oltean
2022-03-22 13:21                                   ` [Bridge] " Hans Schultz
2022-03-22 13:21                                     ` Hans Schultz
2022-03-22 14:47                                     ` [Bridge] " Hans Schultz
2022-03-22 14:47                                       ` Hans Schultz
2022-03-23 10:13                                   ` [Bridge] " Hans Schultz
2022-03-23 10:13                                     ` Hans Schultz
2022-03-23 10:16                                     ` [Bridge] " Vladimir Oltean
2022-03-23 10:16                                       ` Vladimir Oltean
2022-03-23 10:46                                       ` [Bridge] " Hans Schultz
2022-03-23 10:46                                         ` Hans Schultz
2022-03-23 10:57                                       ` [Bridge] " Hans Schultz
2022-03-23 10:57                                         ` Hans Schultz
2022-03-23 11:21                                         ` [Bridge] " Vladimir Oltean
2022-03-23 11:21                                           ` Vladimir Oltean
2022-03-23 11:43                                           ` [Bridge] " Hans Schultz
2022-03-23 11:43                                             ` Hans Schultz
2022-03-23 11:54                                             ` [Bridge] " Vladimir Oltean
2022-03-23 11:54                                               ` Vladimir Oltean
2022-03-21 14:51             ` [Bridge] " Hans Schultz
2022-03-21 14:51               ` Hans Schultz
2022-03-10 14:54   ` [Bridge] " Andrew Lunn
2022-03-10 14:54     ` Andrew Lunn
2022-03-11  7:59     ` Hans Schultz [this message]
2022-03-11  7:59       ` Hans Schultz
2022-03-14 15:50 ` [Bridge] [PATCH net-next 0/3] Extend locked port feature with FDB locked flag (MAC-Auth/MAB) Ido Schimmel
2022-03-14 15:50   ` Ido Schimmel
2022-03-15  8:59   ` [Bridge] " Hans Schultz
2022-03-15  8:59     ` Hans Schultz
2022-03-15 11:11     ` [Bridge] " Ido Schimmel
2022-03-15 11:11       ` Ido Schimmel
2022-03-17  0:18 ` [Bridge] " Florian Fainelli
2022-03-17  0:18   ` Florian Fainelli
2022-03-17  8:29   ` [Bridge] " Hans Schultz
2022-03-17  8:29     ` Hans Schultz
2022-03-17 18:42     ` [Bridge] " Vladimir Oltean
2022-03-17 18:42       ` Vladimir Oltean

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=86y21gvs1j.fsf@gmail.com \
    --to=schultz.hans@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=bridge@lists.linux-foundation.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=idosch@nvidia.com \
    --cc=ivecera@redhat.com \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=razor@blackwall.org \
    --cc=roopa@nvidia.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 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.