From: Saeed Mahameed <saeed@kernel.org>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Network Development <netdev@vger.kernel.org>,
Maxim Mikityanskiy <maximmi@mellanox.com>,
Tariq Toukan <tariqt@nvidia.com>
Subject: Re: [net 11/12] net/mlx5e: Revert parameters on errors when changing MTU and LRO state without reset
Date: Wed, 27 Jan 2021 15:06:30 -0800 [thread overview]
Message-ID: <76eaee81f200b57d00b9b0f9084267832db01337.camel@kernel.org> (raw)
In-Reply-To: <CAF=yD-+DGf_PAQzWScXR7O2J5WY2G5maxMbDQQCNbJXYE6R1Mw@mail.gmail.com>
On Wed, 2021-01-27 at 15:00 -0500, Willem de Bruijn wrote:
> On Wed, Jan 27, 2021 at 3:58 AM Saeed Mahameed <saeedm@nvidia.com>
> wrote:
> >
> > From: Maxim Mikityanskiy <maximmi@mellanox.com>
> >
> > Sometimes, channel params are changed without recreating the
> > channels.
> > It happens in two basic cases: when the channels are closed, and
> > when
> > the parameter being changed doesn't affect how channels are
> > configured.
> > Such changes invoke a hardware command that might fail. The whole
> > operation should be reverted in such cases, but the code that
> > restores
> > the parameters' values in the driver was missing. This commit adds
> > this
> > handling.
> >
> > Fixes: 2e20a151205b ("net/mlx5e: Fail safe mtu and lro setting")
> > Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com>
> > Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
> > Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
> > ---
> > .../net/ethernet/mellanox/mlx5/core/en_main.c | 30 +++++++++++++--
> > ----
> > 1 file changed, 21 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> > b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> > index ac76d32bad7d..a9d824a9cb05 100644
> > --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> > @@ -3764,7 +3764,7 @@ static int set_feature_lro(struct net_device
> > *netdev, bool enable)
> > struct mlx5e_priv *priv = netdev_priv(netdev);
> > struct mlx5_core_dev *mdev = priv->mdev;
> > struct mlx5e_channels new_channels = {};
> > - struct mlx5e_params *old_params;
> > + struct mlx5e_params *cur_params;
> > int err = 0;
> > bool reset;
> >
> > @@ -3777,8 +3777,8 @@ static int set_feature_lro(struct net_device
> > *netdev, bool enable)
> > goto out;
> > }
> >
> > - old_params = &priv->channels.params;
> > - if (enable && !MLX5E_GET_PFLAG(old_params,
> > MLX5E_PFLAG_RX_STRIDING_RQ)) {
> > + cur_params = &priv->channels.params;
> > + if (enable && !MLX5E_GET_PFLAG(cur_params,
> > MLX5E_PFLAG_RX_STRIDING_RQ)) {
> > netdev_warn(netdev, "can't set LRO with legacy
> > RQ\n");
> > err = -EINVAL;
> > goto out;
> > @@ -3786,18 +3786,23 @@ static int set_feature_lro(struct
> > net_device *netdev, bool enable)
> >
> > reset = test_bit(MLX5E_STATE_OPENED, &priv->state);
> >
> > - new_channels.params = *old_params;
> > + new_channels.params = *cur_params;
> > new_channels.params.lro_en = enable;
> >
> > - if (old_params->rq_wq_type != MLX5_WQ_TYPE_CYCLIC) {
> > - if (mlx5e_rx_mpwqe_is_linear_skb(mdev, old_params,
> > NULL) ==
> > + if (cur_params->rq_wq_type != MLX5_WQ_TYPE_CYCLIC) {
> > + if (mlx5e_rx_mpwqe_is_linear_skb(mdev, cur_params,
> > NULL) ==
> > mlx5e_rx_mpwqe_is_linear_skb(mdev,
> > &new_channels.params, NULL))
> > reset = false;
> > }
> >
> > if (!reset) {
> > - *old_params = new_channels.params;
> > + struct mlx5e_params old_params;
> > +
> > + old_params = *cur_params;
> > + *cur_params = new_channels.params;
> > err = mlx5e_modify_tirs_lro(priv);
> > + if (err)
> > + *cur_params = old_params;
>
> No need to explicitly save and restore all params if the only one
> changed is lro_en?
not a big deal, this is a practice we follow in all of our unwind
procedures,
the code will change in net-next to use a generic function that would
restore all params regardless of what changed and what not .. so we
figured to have a one flow that will be easy to replace in net-next.
next prev parent reply other threads:[~2021-01-27 23:22 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-26 23:43 [pull request][net 00/12] mlx5 fixes 2021-01-26 Saeed Mahameed
2021-01-26 23:43 ` [net 01/12] net/mlx5: Fix memory leak on flow table creation error flow Saeed Mahameed
2021-01-28 3:30 ` patchwork-bot+netdevbpf
2021-01-28 8:33 ` Saeed Mahameed
2021-01-29 1:37 ` Jakub Kicinski
2021-01-26 23:43 ` [net 02/12] net/mlx5e: E-switch, Fix rate calculation for overflow Saeed Mahameed
2021-01-26 23:43 ` [net 03/12] net/mlx5e: free page before return Saeed Mahameed
2021-01-26 23:43 ` [net 04/12] net/mlx5e: Reduce tc unsupported key print level Saeed Mahameed
2021-01-26 23:43 ` [net 05/12] net/mlx5e: Fix IPSEC stats Saeed Mahameed
2021-01-26 23:43 ` [net 06/12] net/mlx5: Maintain separate page trees for ECPF and PF functions Saeed Mahameed
2021-01-26 23:43 ` [net 07/12] net/mlx5e: Disable hw-tc-offload when MLX5_CLS_ACT config is disabled Saeed Mahameed
2021-01-26 23:43 ` [net 08/12] net/mlx5e: Fix CT rule + encap slow path offload and deletion Saeed Mahameed
2021-01-26 23:43 ` [net 09/12] net/mlx5e: Correctly handle changing the number of queues when the interface is down Saeed Mahameed
2021-01-26 23:43 ` [net 10/12] net/mlx5e: Revert parameters on errors when changing trust state without reset Saeed Mahameed
2021-01-26 23:43 ` [net 11/12] net/mlx5e: Revert parameters on errors when changing MTU and LRO " Saeed Mahameed
2021-01-27 20:00 ` Willem de Bruijn
2021-01-27 23:06 ` Saeed Mahameed [this message]
2021-01-26 23:43 ` [net 12/12] net/mlx5: CT: Fix incorrect removal of tuple_nat_node from nat rhashtable Saeed Mahameed
2021-01-27 20:03 ` [pull request][net 00/12] mlx5 fixes 2021-01-26 Willem de Bruijn
2021-01-27 23:08 ` Saeed Mahameed
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=76eaee81f200b57d00b9b0f9084267832db01337.camel@kernel.org \
--to=saeed@kernel.org \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=maximmi@mellanox.com \
--cc=netdev@vger.kernel.org \
--cc=tariqt@nvidia.com \
--cc=willemdebruijn.kernel@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).