All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Laurent Vivier <lvivier@redhat.com>
Cc: "Cindy Lu" <lulu@redhat.com>,
	"David S. Miller" <davem@davemloft.net>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	"Eugenio Pérez" <eperezma@redhat.com>,
	"Gautam Dawar" <gautam.dawar@xilinx.com>,
	"Eli Cohen" <elic@nvidia.com>
Subject: Re: [PATCH v2 1/1] virtio_net: notify MAC address change on device initialization
Date: Tue, 24 Jan 2023 05:15:17 -0500	[thread overview]
Message-ID: <20230124024711-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20230123120022.2364889-2-lvivier@redhat.com>

On Mon, Jan 23, 2023 at 01:00:22PM +0100, Laurent Vivier wrote:
> In virtnet_probe(), if the device doesn't provide a MAC address the
> driver assigns a random one.
> As we modify the MAC address we need to notify the device to allow it
> to update all the related information.
> 
> The problem can be seen with vDPA and mlx5_vdpa driver as it doesn't
> assign a MAC address by default. The virtio_net device uses a random
> MAC address (we can see it with "ip link"), but we can't ping a net
> namespace from another one using the virtio-vdpa device because the
> new MAC address has not been provided to the hardware.

And then what exactly happens? Does hardware drop the outgoing
or the incoming packets? Pls include in the commit log.

> Signed-off-by: Laurent Vivier <lvivier@redhat.com>
> ---
>  drivers/net/virtio_net.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 7723b2a49d8e..4bdc8286678b 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -3800,6 +3800,8 @@ static int virtnet_probe(struct virtio_device *vdev)
>  		eth_hw_addr_set(dev, addr);
>  	} else {
>  		eth_hw_addr_random(dev);
> +		dev_info(&vdev->dev, "Assigned random MAC address %pM\n",
> +			 dev->dev_addr);
>  	}
>  
>  	/* Set up our device-specific information */
> @@ -3956,6 +3958,18 @@ static int virtnet_probe(struct virtio_device *vdev)
>  	pr_debug("virtnet: registered device %s with %d RX and TX vq's\n",
>  		 dev->name, max_queue_pairs);
>  
> +	/* a random MAC address has been assigned, notify the device */
> +	if (!virtio_has_feature(vdev, VIRTIO_NET_F_MAC) &&
> +	    virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_MAC_ADDR)) {

Maybe add a comment explaining that we don't fail probe if
VIRTIO_NET_F_CTRL_MAC_ADDR is not there because
many devices work fine without getting MAC explicitly.

> +		struct scatterlist sg;
> +
> +		sg_init_one(&sg, dev->dev_addr, dev->addr_len);
> +		if (!virtnet_send_command(vi, VIRTIO_NET_CTRL_MAC,
> +					  VIRTIO_NET_CTRL_MAC_ADDR_SET, &sg)) {
> +			dev_warn(&vdev->dev, "Failed to update MAC address.\n");

Here, I'm not sure we want to proceed. Is it useful sometimes?
I note that we deny with virtnet_set_mac_address.

> +		}
> +	}
> +
>  	return 0;



Also, some code duplication with virtnet_set_mac_address here.

Also:
	When using the legacy interface, \field{mac} is driver-writable
	which provided a way for drivers to update the MAC without
	negotiating VIRTIO_NET_F_CTRL_MAC_ADDR.

How about factoring out code in virtnet_set_mac_address
and reusing that?


This will also handle corner cases such as VIRTIO_NET_F_STANDBY
which are not currently addressed.


>  free_unregister_netdev:
> -- 
> 2.39.0

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Laurent Vivier <lvivier@redhat.com>
Cc: linux-kernel@vger.kernel.org,
	"Gautam Dawar" <gautam.dawar@xilinx.com>,
	"Eugenio Pérez" <eperezma@redhat.com>,
	netdev@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	"Eli Cohen" <elic@nvidia.com>, "Cindy Lu" <lulu@redhat.com>,
	"Jason Wang" <jasowang@redhat.com>,
	"David S. Miller" <davem@davemloft.net>,
	"Parav Pandit" <parav@nvidia.com>
Subject: Re: [PATCH v2 1/1] virtio_net: notify MAC address change on device initialization
Date: Tue, 24 Jan 2023 05:15:17 -0500	[thread overview]
Message-ID: <20230124024711-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20230123120022.2364889-2-lvivier@redhat.com>

On Mon, Jan 23, 2023 at 01:00:22PM +0100, Laurent Vivier wrote:
> In virtnet_probe(), if the device doesn't provide a MAC address the
> driver assigns a random one.
> As we modify the MAC address we need to notify the device to allow it
> to update all the related information.
> 
> The problem can be seen with vDPA and mlx5_vdpa driver as it doesn't
> assign a MAC address by default. The virtio_net device uses a random
> MAC address (we can see it with "ip link"), but we can't ping a net
> namespace from another one using the virtio-vdpa device because the
> new MAC address has not been provided to the hardware.

And then what exactly happens? Does hardware drop the outgoing
or the incoming packets? Pls include in the commit log.

> Signed-off-by: Laurent Vivier <lvivier@redhat.com>
> ---
>  drivers/net/virtio_net.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 7723b2a49d8e..4bdc8286678b 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -3800,6 +3800,8 @@ static int virtnet_probe(struct virtio_device *vdev)
>  		eth_hw_addr_set(dev, addr);
>  	} else {
>  		eth_hw_addr_random(dev);
> +		dev_info(&vdev->dev, "Assigned random MAC address %pM\n",
> +			 dev->dev_addr);
>  	}
>  
>  	/* Set up our device-specific information */
> @@ -3956,6 +3958,18 @@ static int virtnet_probe(struct virtio_device *vdev)
>  	pr_debug("virtnet: registered device %s with %d RX and TX vq's\n",
>  		 dev->name, max_queue_pairs);
>  
> +	/* a random MAC address has been assigned, notify the device */
> +	if (!virtio_has_feature(vdev, VIRTIO_NET_F_MAC) &&
> +	    virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_MAC_ADDR)) {

Maybe add a comment explaining that we don't fail probe if
VIRTIO_NET_F_CTRL_MAC_ADDR is not there because
many devices work fine without getting MAC explicitly.

> +		struct scatterlist sg;
> +
> +		sg_init_one(&sg, dev->dev_addr, dev->addr_len);
> +		if (!virtnet_send_command(vi, VIRTIO_NET_CTRL_MAC,
> +					  VIRTIO_NET_CTRL_MAC_ADDR_SET, &sg)) {
> +			dev_warn(&vdev->dev, "Failed to update MAC address.\n");

Here, I'm not sure we want to proceed. Is it useful sometimes?
I note that we deny with virtnet_set_mac_address.

> +		}
> +	}
> +
>  	return 0;



Also, some code duplication with virtnet_set_mac_address here.

Also:
	When using the legacy interface, \field{mac} is driver-writable
	which provided a way for drivers to update the MAC without
	negotiating VIRTIO_NET_F_CTRL_MAC_ADDR.

How about factoring out code in virtnet_set_mac_address
and reusing that?


This will also handle corner cases such as VIRTIO_NET_F_STANDBY
which are not currently addressed.


>  free_unregister_netdev:
> -- 
> 2.39.0


  reply	other threads:[~2023-01-24 10:15 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-23 12:00 [PATCH v2 0/1] virtio_net: vdpa: update MAC address when it is generated by virtio-net Laurent Vivier
2023-01-23 12:00 ` Laurent Vivier
2023-01-23 12:00 ` [PATCH v2 1/1] virtio_net: notify MAC address change on device initialization Laurent Vivier
2023-01-23 12:00   ` Laurent Vivier
2023-01-24 10:15   ` Michael S. Tsirkin [this message]
2023-01-24 10:15     ` Michael S. Tsirkin
2023-01-24 11:04     ` Laurent Vivier
2023-01-24 11:04       ` Laurent Vivier
2023-01-25  7:13       ` Eli Cohen
2023-01-27 11:08       ` Michael S. Tsirkin
2023-01-27 11:08         ` Michael S. Tsirkin
2023-01-27 12:28         ` Laurent Vivier
2023-01-27 12:28           ` Laurent Vivier
2023-01-27 14:53           ` Michael S. Tsirkin
2023-01-27 14:53             ` Michael S. Tsirkin

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=20230124024711-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=davem@davemloft.net \
    --cc=elic@nvidia.com \
    --cc=eperezma@redhat.com \
    --cc=gautam.dawar@xilinx.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lulu@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=netdev@vger.kernel.org \
    --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.