From: "Michael S. Tsirkin" <mst@redhat.com>
To: Parav Pandit <parav@nvidia.com>
Cc: "lvivier@redhat.com" <lvivier@redhat.com>,
"virtualization@lists.linux-foundation.org"
<virtualization@lists.linux-foundation.org>,
"eperezma@redhat.com" <eperezma@redhat.com>,
"si-wei.liu@oracle.com" <si-wei.liu@oracle.com>,
Eli Cohen <elic@nvidia.com>
Subject: Re: [PATCH] net/mlx5_vdpa: Offer VIRTIO_NET_F_MTU when setting MTU
Date: Thu, 25 Nov 2021 15:42:41 -0500 [thread overview]
Message-ID: <20211125154011-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <PH0PR12MB548163DC0306DB2EF50B76F3DC629@PH0PR12MB5481.namprd12.prod.outlook.com>
On Thu, Nov 25, 2021 at 06:27:15PM +0000, Parav Pandit wrote:
>
>
> > From: Eli Cohen <elic@nvidia.com>
> > Sent: Thursday, November 25, 2021 1:32 PM
> >
> > On Thu, Nov 25, 2021 at 07:29:18AM +0200, Parav Pandit wrote:
> > >
> > >
> > > > From: Eli Cohen <elic@nvidia.com>
> > > > Sent: Wednesday, November 24, 2021 10:40 PM
> > > >
> > > > Make sure to offer VIRTIO_NET_F_MTU since we configure the MTU based
> > > > on what was queried from the device.
> > > >
> > > > This allows the virtio driver to allocate large enough buffers based
> > > > on the reported MTU.
> > > >
> > > > Signed-off-by: Eli Cohen <elic@nvidia.com>
> > > > ---
> > > > drivers/vdpa/mlx5/net/mlx5_vnet.c | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > index 465e832f2ad1..ed7a63e48335 100644
> > > > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > @@ -1956,6 +1956,7 @@ static u64 mlx5_vdpa_get_features(struct
> > > > vdpa_device *vdev)
> > > > ndev->mvdev.mlx_features |=
> > > > BIT_ULL(VIRTIO_NET_F_CTRL_MAC_ADDR);
> > > > ndev->mvdev.mlx_features |= BIT_ULL(VIRTIO_NET_F_MQ);
> > > > ndev->mvdev.mlx_features |= BIT_ULL(VIRTIO_NET_F_STATUS);
> > > > + ndev->mvdev.mlx_features |= BIT_ULL(VIRTIO_NET_F_MTU);
> > > It is better to set this feature bit along with the writing the RO config.mtu
> > area, adjacent to query_mtu() call.
> >
> > Why is that so important? We always query the mtu and if the query fails, we
> > fail the initialization so it does not look critical.
> It is not so important. But it is more appropriate to set read only field and its associated feature bit at one place, which never changes.
> There is no need to perform OR operation for those many feature bits on every get_features() callback when they are immutable.
>
> So I wanted to move setting other 5 feature bits assignment at one place in device initialization time similar to how you have done VALID_FEATURES_MASK.
> Something like below.
> But again, its minor.
> If you happen to revise the series (I think you should for the supporting dumpit in future), please consider one time assignment like below.
>
> diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> index 63813fbb5f62..21802b25b0f5 100644
> --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> @@ -1890,11 +1890,6 @@ static u64 mlx5_vdpa_get_features(struct vdpa_device *vdev)
> ndev->mvdev.mlx_features |= mlx_to_vritio_features(dev_features);
> if (MLX5_CAP_DEV_VDPA_EMULATION(mvdev->mdev, virtio_version_1_0))
> ndev->mvdev.mlx_features |= BIT_ULL(VIRTIO_F_VERSION_1);
> - ndev->mvdev.mlx_features |= BIT_ULL(VIRTIO_F_ACCESS_PLATFORM);
> - ndev->mvdev.mlx_features |= BIT_ULL(VIRTIO_NET_F_CTRL_VQ);
> - ndev->mvdev.mlx_features |= BIT_ULL(VIRTIO_NET_F_CTRL_MAC_ADDR);
> - ndev->mvdev.mlx_features |= BIT_ULL(VIRTIO_NET_F_MQ);
> - ndev->mvdev.mlx_features |= BIT_ULL(VIRTIO_NET_F_STATUS);
>
> print_features(mvdev, ndev->mvdev.mlx_features, false);
> return ndev->mvdev.mlx_features;
> @@ -2522,6 +2517,14 @@ static int event_handler(struct notifier_block *nb, unsigned long event, void *p
> return ret;
> }
>
> +#define DEFAULT_FEATURES \
> + BIT_ULL(VIRTIO_F_ACCESS_PLATFORM) | \
> + BIT_ULL(VIRTIO_NET_F_CTRL_VQ) | \
> + BIT_ULL(VIRTIO_NET_F_CTRL_MAC_ADDR) \
> + BIT_ULL(VIRTIO_NET_F_MQ) \
> + BIT_ULL(VIRTIO_NET_F_STATUS) \
> + BIT_ULL(VIRTIO_NET_F_MTU)
> +
I would just open-code it, don't see what good does the macro do.
A single assignment is a bit clearer I think I agree,
there's not much of a difference.
> static int mlx5_vdpa_dev_add(struct vdpa_mgmt_dev *v_mdev, const char *name,
> const struct vdpa_dev_set_config *add_config)
> {
> @@ -2565,6 +2568,7 @@ static int mlx5_vdpa_dev_add(struct vdpa_mgmt_dev *v_mdev, const char *name,
> goto err_mtu;
>
> ndev->config.mtu = cpu_to_mlx5vdpa16(mvdev, mtu);
> + ndev->mvdev.mlx_features = DEFAULT_FEATURES;
>
> if (get_link_state(mvdev))
> ndev->config.status |= cpu_to_mlx5vdpa16(mvdev, VIRTIO_NET_S_LINK_UP);
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
prev parent reply other threads:[~2021-11-25 20:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20211124170949.51725-1-elic@nvidia.com>
2021-11-24 23:47 ` [PATCH] net/mlx5_vdpa: Offer VIRTIO_NET_F_MTU when setting MTU Si-Wei Liu
2021-11-25 4:37 ` Jason Wang
2021-11-25 5:29 ` Parav Pandit via Virtualization
[not found] ` <20211125080227.GE214101@mtl-vdi-166.wap.labs.mlnx>
2021-11-25 18:27 ` Parav Pandit via Virtualization
2021-11-25 20:42 ` Michael S. Tsirkin [this message]
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=20211125154011-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=elic@nvidia.com \
--cc=eperezma@redhat.com \
--cc=lvivier@redhat.com \
--cc=parav@nvidia.com \
--cc=si-wei.liu@oracle.com \
--cc=virtualization@lists.linux-foundation.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 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.