All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <simon.horman@corigine.com>
To: Wojciech Drewek <wojciech.drewek@intel.com>
Cc: pmenzel@molgen.mpg.de, netdev@vger.kernel.org,
	Jakub Kicinski <kuba@kernel.org>,
	Eric Dumazet <edumazet@google.com>,
	intel-wired-lan@lists.osuosl.org, dan.carpenter@linaro.org
Subject: Re: [Intel-wired-lan] [PATCH iwl-next v4 07/13] ice: Switchdev FDB events support
Date: Sun, 4 Jun 2023 16:17:44 +0200	[thread overview]
Message-ID: <ZHydCI08zJip88rj@corigine.com> (raw)
In-Reply-To: <20230524122121.15012-8-wojciech.drewek@intel.com>

+ Jakub, Eric

On Wed, May 24, 2023 at 02:21:15PM +0200, Wojciech Drewek wrote:
> Listen for SWITCHDEV_FDB_{ADD|DEL}_TO_DEVICE events while in switchdev
> mode. Accept these events on both uplink and VF PR ports. Add HW
> rules in newly created workqueue. FDB entries are stored in rhashtable
> for lookup when removing the entry and in the list for cleanup
> purpose. Direction of the HW rule depends on the type of the ports
> on which the FDB event was received:
> 
> ICE_ESWITCH_BR_UPLINK_PORT:
> TX rule that forwards the packet to the LAN (egress).
> 
> ICE_ESWITCH_BR_VF_REPR_PORT:
> RX rule that forwards the packet to the VF associated
> with the port representor.
> 
> In both cases the rule matches on the dst mac address.
> All the FDB entries are stored in the bridge structure.
> When the port is removed all the FDB entries associated with
> this port are removed as well. This is achieved thanks to the reference
> to the port that FDB entry holds.
> 
> In the fwd rule we use only one lookup type (MAC address)
> but lkups_cnt variable is already introduced because
> we will have more lookups in the subsequent patches.
> 
> Signed-off-by: Wojciech Drewek <wojciech.drewek@intel.com>

...

> +static void
> +ice_eswitch_br_fdb_event_work(struct work_struct *work)
> +{
> +	struct ice_esw_br_fdb_work *fdb_work = ice_work_to_fdb_work(work);
> +	bool added_by_user = fdb_work->fdb_info.added_by_user;
> +	struct ice_esw_br_port *br_port = fdb_work->br_port;
> +	const unsigned char *mac = fdb_work->fdb_info.addr;
> +	u16 vid = fdb_work->fdb_info.vid;
> +
> +	rtnl_lock();
> +
> +	if (!br_port || !br_port->bridge)
> +		goto err_exit;
> +
> +	switch (fdb_work->event) {
> +	case SWITCHDEV_FDB_ADD_TO_DEVICE:
> +		ice_eswitch_br_fdb_entry_create(fdb_work->dev, br_port,
> +						added_by_user, mac, vid);
> +		break;
> +	case SWITCHDEV_FDB_DEL_TO_DEVICE:
> +		ice_eswitch_br_fdb_entry_find_and_delete(br_port->bridge,
> +							 mac, vid);
> +		break;
> +	default:
> +		goto err_exit;
> +	}
> +
> +err_exit:
> +	rtnl_unlock();
> +	dev_put(fdb_work->dev);

Hi Wojciech,

I notice that the CI flags this as use of a deprecated API.
So I'm wondering if it would be better written using netdev_put()
And likewise, I'm wondering if other users in the ice driver should be
updated.

> +	ice_eswitch_br_fdb_work_dealloc(fdb_work);
> +}

...

> +static int
> +ice_eswitch_br_switchdev_event(struct notifier_block *nb,
> +			       unsigned long event, void *ptr)
> +{
> +	struct net_device *dev = switchdev_notifier_info_to_dev(ptr);
> +	struct switchdev_notifier_fdb_info *fdb_info;
> +	struct switchdev_notifier_info *info = ptr;
> +	struct ice_esw_br_offloads *br_offloads;
> +	struct ice_esw_br_fdb_work *work;
> +	struct ice_esw_br_port *br_port;
> +	struct netlink_ext_ack *extack;
> +	struct net_device *upper;
> +
> +	br_offloads = ice_nb_to_br_offloads(nb, switchdev_nb);
> +	extack = switchdev_notifier_info_to_extack(ptr);
> +
> +	upper = netdev_master_upper_dev_get_rcu(dev);
> +	if (!upper)
> +		return NOTIFY_DONE;
> +
> +	if (!netif_is_bridge_master(upper))
> +		return NOTIFY_DONE;
> +
> +	if (!ice_eswitch_br_is_dev_valid(dev))
> +		return NOTIFY_DONE;
> +
> +	br_port = ice_eswitch_br_netdev_to_port(dev);
> +	if (!br_port)
> +		return NOTIFY_DONE;
> +
> +	switch (event) {
> +	case SWITCHDEV_FDB_ADD_TO_DEVICE:
> +	case SWITCHDEV_FDB_DEL_TO_DEVICE:
> +		fdb_info = container_of(info, typeof(*fdb_info), info);
> +
> +		work = ice_eswitch_br_fdb_work_alloc(fdb_info, br_port, dev,
> +						     event);
> +		if (IS_ERR(work)) {
> +			NL_SET_ERR_MSG_MOD(extack, "Failed to init switchdev fdb work");
> +			return notifier_from_errno(PTR_ERR(work));
> +		}
> +		dev_hold(dev);

Likewise, I'm wondering if this should be netdev_hold().

> +
> +		queue_work(br_offloads->wq, &work->work);
> +		break;
> +	default:
> +		break;
> +	}
> +	return NOTIFY_DONE;
> +}
> +

...
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

WARNING: multiple messages have this Message-ID (diff)
From: Simon Horman <simon.horman@corigine.com>
To: Wojciech Drewek <wojciech.drewek@intel.com>
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
	alexandr.lobakin@intel.com, david.m.ertman@intel.com,
	michal.swiatkowski@linux.intel.com,
	marcin.szycik@linux.intel.com, pawel.chmielewski@intel.com,
	sridhar.samudrala@intel.com, pmenzel@molgen.mpg.de,
	dan.carpenter@linaro.org, Jakub Kicinski <kuba@kernel.org>,
	Eric Dumazet <edumazet@google.com>
Subject: Re: [PATCH iwl-next v4 07/13] ice: Switchdev FDB events support
Date: Sun, 4 Jun 2023 16:17:44 +0200	[thread overview]
Message-ID: <ZHydCI08zJip88rj@corigine.com> (raw)
In-Reply-To: <20230524122121.15012-8-wojciech.drewek@intel.com>

+ Jakub, Eric

On Wed, May 24, 2023 at 02:21:15PM +0200, Wojciech Drewek wrote:
> Listen for SWITCHDEV_FDB_{ADD|DEL}_TO_DEVICE events while in switchdev
> mode. Accept these events on both uplink and VF PR ports. Add HW
> rules in newly created workqueue. FDB entries are stored in rhashtable
> for lookup when removing the entry and in the list for cleanup
> purpose. Direction of the HW rule depends on the type of the ports
> on which the FDB event was received:
> 
> ICE_ESWITCH_BR_UPLINK_PORT:
> TX rule that forwards the packet to the LAN (egress).
> 
> ICE_ESWITCH_BR_VF_REPR_PORT:
> RX rule that forwards the packet to the VF associated
> with the port representor.
> 
> In both cases the rule matches on the dst mac address.
> All the FDB entries are stored in the bridge structure.
> When the port is removed all the FDB entries associated with
> this port are removed as well. This is achieved thanks to the reference
> to the port that FDB entry holds.
> 
> In the fwd rule we use only one lookup type (MAC address)
> but lkups_cnt variable is already introduced because
> we will have more lookups in the subsequent patches.
> 
> Signed-off-by: Wojciech Drewek <wojciech.drewek@intel.com>

...

> +static void
> +ice_eswitch_br_fdb_event_work(struct work_struct *work)
> +{
> +	struct ice_esw_br_fdb_work *fdb_work = ice_work_to_fdb_work(work);
> +	bool added_by_user = fdb_work->fdb_info.added_by_user;
> +	struct ice_esw_br_port *br_port = fdb_work->br_port;
> +	const unsigned char *mac = fdb_work->fdb_info.addr;
> +	u16 vid = fdb_work->fdb_info.vid;
> +
> +	rtnl_lock();
> +
> +	if (!br_port || !br_port->bridge)
> +		goto err_exit;
> +
> +	switch (fdb_work->event) {
> +	case SWITCHDEV_FDB_ADD_TO_DEVICE:
> +		ice_eswitch_br_fdb_entry_create(fdb_work->dev, br_port,
> +						added_by_user, mac, vid);
> +		break;
> +	case SWITCHDEV_FDB_DEL_TO_DEVICE:
> +		ice_eswitch_br_fdb_entry_find_and_delete(br_port->bridge,
> +							 mac, vid);
> +		break;
> +	default:
> +		goto err_exit;
> +	}
> +
> +err_exit:
> +	rtnl_unlock();
> +	dev_put(fdb_work->dev);

Hi Wojciech,

I notice that the CI flags this as use of a deprecated API.
So I'm wondering if it would be better written using netdev_put()
And likewise, I'm wondering if other users in the ice driver should be
updated.

> +	ice_eswitch_br_fdb_work_dealloc(fdb_work);
> +}

...

> +static int
> +ice_eswitch_br_switchdev_event(struct notifier_block *nb,
> +			       unsigned long event, void *ptr)
> +{
> +	struct net_device *dev = switchdev_notifier_info_to_dev(ptr);
> +	struct switchdev_notifier_fdb_info *fdb_info;
> +	struct switchdev_notifier_info *info = ptr;
> +	struct ice_esw_br_offloads *br_offloads;
> +	struct ice_esw_br_fdb_work *work;
> +	struct ice_esw_br_port *br_port;
> +	struct netlink_ext_ack *extack;
> +	struct net_device *upper;
> +
> +	br_offloads = ice_nb_to_br_offloads(nb, switchdev_nb);
> +	extack = switchdev_notifier_info_to_extack(ptr);
> +
> +	upper = netdev_master_upper_dev_get_rcu(dev);
> +	if (!upper)
> +		return NOTIFY_DONE;
> +
> +	if (!netif_is_bridge_master(upper))
> +		return NOTIFY_DONE;
> +
> +	if (!ice_eswitch_br_is_dev_valid(dev))
> +		return NOTIFY_DONE;
> +
> +	br_port = ice_eswitch_br_netdev_to_port(dev);
> +	if (!br_port)
> +		return NOTIFY_DONE;
> +
> +	switch (event) {
> +	case SWITCHDEV_FDB_ADD_TO_DEVICE:
> +	case SWITCHDEV_FDB_DEL_TO_DEVICE:
> +		fdb_info = container_of(info, typeof(*fdb_info), info);
> +
> +		work = ice_eswitch_br_fdb_work_alloc(fdb_info, br_port, dev,
> +						     event);
> +		if (IS_ERR(work)) {
> +			NL_SET_ERR_MSG_MOD(extack, "Failed to init switchdev fdb work");
> +			return notifier_from_errno(PTR_ERR(work));
> +		}
> +		dev_hold(dev);

Likewise, I'm wondering if this should be netdev_hold().

> +
> +		queue_work(br_offloads->wq, &work->work);
> +		break;
> +	default:
> +		break;
> +	}
> +	return NOTIFY_DONE;
> +}
> +

...

  reply	other threads:[~2023-06-04 14:17 UTC|newest]

Thread overview: 98+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-24 12:21 [Intel-wired-lan] [PATCH iwl-next v4 00/13] ice: switchdev bridge offload Wojciech Drewek
2023-05-24 12:21 ` Wojciech Drewek
2023-05-24 12:21 ` [Intel-wired-lan] [PATCH iwl-next v4 01/13] ice: Skip adv rules removal upon switchdev release Wojciech Drewek
2023-05-24 12:21   ` Wojciech Drewek
2023-06-04  8:17   ` [Intel-wired-lan] " Simon Horman
2023-06-04  8:17     ` Simon Horman
2023-06-05 10:27     ` [Intel-wired-lan] " Drewek, Wojciech
2023-06-05 10:27       ` Drewek, Wojciech
2023-06-07  5:49   ` [Intel-wired-lan] " Buvaneswaran, Sujai
2023-06-07  5:49     ` Buvaneswaran, Sujai
2023-05-24 12:21 ` [Intel-wired-lan] [PATCH iwl-next v4 02/13] ice: Prohibit rx mode change in switchdev mode Wojciech Drewek
2023-05-24 12:21   ` Wojciech Drewek
2023-06-04 13:59   ` [Intel-wired-lan] " Simon Horman
2023-06-04 13:59     ` Simon Horman
2023-06-12  7:30   ` [Intel-wired-lan] " Buvaneswaran, Sujai
2023-06-12  7:30     ` Buvaneswaran, Sujai
2023-06-13  9:41     ` Drewek, Wojciech
2023-06-13  9:41       ` Drewek, Wojciech
2023-06-13 10:14   ` Buvaneswaran, Sujai
2023-06-13 10:14     ` Buvaneswaran, Sujai
2023-06-13 10:14   ` Buvaneswaran, Sujai
2023-06-13 10:14     ` Buvaneswaran, Sujai
2023-05-24 12:21 ` [Intel-wired-lan] [PATCH iwl-next v4 03/13] ice: Don't tx before switchdev is fully configured Wojciech Drewek
2023-05-24 12:21   ` Wojciech Drewek
2023-06-04 14:00   ` [Intel-wired-lan] " Simon Horman
2023-06-04 14:00     ` Simon Horman
2023-06-07  5:57   ` [Intel-wired-lan] " Buvaneswaran, Sujai
2023-06-07  5:57     ` Buvaneswaran, Sujai
2023-05-24 12:21 ` [Intel-wired-lan] [PATCH iwl-next v4 04/13] ice: Disable vlan pruning for uplink VSI Wojciech Drewek
2023-05-24 12:21   ` Wojciech Drewek
2023-06-04 14:01   ` [Intel-wired-lan] " Simon Horman
2023-06-04 14:01     ` Simon Horman
2023-06-07  6:00   ` [Intel-wired-lan] " Buvaneswaran, Sujai
2023-06-07  6:00     ` Buvaneswaran, Sujai
2023-05-24 12:21 ` [Intel-wired-lan] [PATCH iwl-next v4 05/13] ice: Unset src prune on " Wojciech Drewek
2023-05-24 12:21   ` Wojciech Drewek
2023-06-04 14:02   ` [Intel-wired-lan] " Simon Horman
2023-06-04 14:02     ` Simon Horman
2023-06-07  6:02   ` [Intel-wired-lan] " Buvaneswaran, Sujai
2023-06-07  6:02     ` Buvaneswaran, Sujai
2023-05-24 12:21 ` [Intel-wired-lan] [PATCH iwl-next v4 06/13] ice: Implement basic eswitch bridge setup Wojciech Drewek
2023-05-24 12:21   ` Wojciech Drewek
2023-06-04 13:59   ` [Intel-wired-lan] " Simon Horman
2023-06-04 13:59     ` Simon Horman
2023-06-05 10:47     ` [Intel-wired-lan] " Drewek, Wojciech
2023-06-05 10:47       ` Drewek, Wojciech
2023-06-05 12:02       ` [Intel-wired-lan] " Simon Horman
2023-06-05 12:02         ` Simon Horman
2023-06-07  6:03   ` [Intel-wired-lan] " Buvaneswaran, Sujai
2023-06-07  6:03     ` Buvaneswaran, Sujai
2023-05-24 12:21 ` [Intel-wired-lan] [PATCH iwl-next v4 07/13] ice: Switchdev FDB events support Wojciech Drewek
2023-05-24 12:21   ` Wojciech Drewek
2023-06-04 14:17   ` Simon Horman [this message]
2023-06-04 14:17     ` Simon Horman
2023-06-05 13:53     ` [Intel-wired-lan] " Drewek, Wojciech
2023-06-05 13:53       ` Drewek, Wojciech
2023-06-07  6:06   ` [Intel-wired-lan] " Buvaneswaran, Sujai
2023-06-07  6:06     ` Buvaneswaran, Sujai
2023-05-24 12:21 ` [Intel-wired-lan] [PATCH iwl-next v4 08/13] ice: Add guard rule when creating FDB in switchdev Wojciech Drewek
2023-05-24 12:21   ` Wojciech Drewek
2023-06-04 16:08   ` [Intel-wired-lan] " Simon Horman
2023-06-04 16:08     ` Simon Horman
2023-06-07  6:22   ` [Intel-wired-lan] " Buvaneswaran, Sujai
2023-06-07  6:22     ` Buvaneswaran, Sujai
2023-05-24 12:21 ` [Intel-wired-lan] [PATCH iwl-next v4 09/13] ice: Accept LAG netdevs in bridge offloads Wojciech Drewek
2023-05-24 12:21   ` Wojciech Drewek
2023-06-04 16:06   ` [Intel-wired-lan] " Simon Horman
2023-06-04 16:06     ` Simon Horman
2023-06-05 17:12     ` [Intel-wired-lan] " Drewek, Wojciech
2023-06-05 17:12       ` Drewek, Wojciech
2023-06-06  9:23       ` [Intel-wired-lan] " Simon Horman
2023-06-06  9:23         ` Simon Horman
2023-06-07  6:23   ` [Intel-wired-lan] " Buvaneswaran, Sujai
2023-06-07  6:23     ` Buvaneswaran, Sujai
2023-05-24 12:21 ` [Intel-wired-lan] [PATCH iwl-next v4 10/13] ice: Add VLAN FDB support in switchdev mode Wojciech Drewek
2023-05-24 12:21   ` Wojciech Drewek
2023-06-04 16:37   ` [Intel-wired-lan] " Simon Horman
2023-06-04 16:37     ` Simon Horman
2023-06-05 17:45     ` [Intel-wired-lan] " Drewek, Wojciech
2023-06-05 17:45       ` Drewek, Wojciech
2023-06-07  6:25   ` [Intel-wired-lan] " Buvaneswaran, Sujai
2023-06-07  6:25     ` Buvaneswaran, Sujai
2023-05-24 12:21 ` [Intel-wired-lan] [PATCH iwl-next v4 11/13] ice: implement bridge port vlan Wojciech Drewek
2023-05-24 12:21   ` Wojciech Drewek
2023-06-04 17:30   ` [Intel-wired-lan] " Simon Horman
2023-06-04 17:30     ` Simon Horman
2023-06-07  6:34   ` [Intel-wired-lan] " Buvaneswaran, Sujai
2023-06-07  6:34     ` Buvaneswaran, Sujai
2023-05-24 12:21 ` [Intel-wired-lan] [PATCH iwl-next v4 12/13] ice: implement static version of ageing Wojciech Drewek
2023-05-24 12:21   ` Wojciech Drewek
2023-06-04 17:31   ` [Intel-wired-lan] " Simon Horman
2023-06-04 17:31     ` Simon Horman
2023-06-07  6:37   ` [Intel-wired-lan] " Buvaneswaran, Sujai
2023-06-07  6:37     ` Buvaneswaran, Sujai
2023-05-24 12:21 ` [Intel-wired-lan] [PATCH iwl-next v4 13/13] ice: add tracepoints for the switchdev bridge Wojciech Drewek
2023-05-24 12:21   ` Wojciech Drewek
2023-06-07  6:39   ` [Intel-wired-lan] " Buvaneswaran, Sujai
2023-06-07  6:39     ` Buvaneswaran, Sujai

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=ZHydCI08zJip88rj@corigine.com \
    --to=simon.horman@corigine.com \
    --cc=dan.carpenter@linaro.org \
    --cc=edumazet@google.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pmenzel@molgen.mpg.de \
    --cc=wojciech.drewek@intel.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.