mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dragos Tatulea <dtatulea@nvidia.com>
To: "Si-Wei Liu" <si-wei.liu@oracle.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Jason Wang" <jasowang@redhat.com>,
	"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
	"Eugenio Pérez" <eperezma@redhat.com>
Cc: Jiri Pirko <jiri@nvidia.com>,
	virtualization@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] vdpa/mlx5: Use random MAC address when no nic vport MAC set
Date: Wed, 28 Aug 2024 09:53:28 +0200	[thread overview]
Message-ID: <5b99338f-56f7-492c-8a85-520badc28518@nvidia.com> (raw)
In-Reply-To: <3d9509c2-f052-be94-db9b-ef501c880415@oracle.com>



On 28.08.24 07:54, Si-Wei Liu wrote:
> 
> 
> On 8/27/2024 9:02 AM, Dragos Tatulea wrote:
>> When the vdpa device is configured without a specific MAC
>> address, the vport MAC address is used. However, this
>> address can be 0 which prevents the driver from properly
>> configuring the MPFS and breaks steering.
>>
>> The solution is to simply generate a random MAC address
>> when no MAC is set on the nic vport.
>>
>> Now it's possible to create a vdpa device without a
>> MAC address and run qemu with this device without needing
>> to configure an explicit MAC address.
>>
>> Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
>> Reviewed-by: Jiri Pirko <jiri@nvidia.com>
>> ---
>>   drivers/vdpa/mlx5/net/mlx5_vnet.c | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c b/drivers/vdpa/mlx5/net/mlx5_vnet.c
>> index fa78e8288ebb..1c26139d02fe 100644
>> --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
>> +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
>> @@ -3824,6 +3824,9 @@ static int mlx5_vdpa_dev_add(struct vdpa_mgmt_dev *v_mdev, const char *name,
>>           err = mlx5_query_nic_vport_mac_address(mdev, 0, 0, config->mac);
>>           if (err)
>>               goto err_alloc;
>> +
>> +        if (is_zero_ether_addr(config->mac))
>> +            eth_random_addr(config->mac);
> I wonder with this change we no longer honor the historical behaviour to retain the zero mac address and clear the _F_MAC bit, should we head to remove the below logic? It looks to me below would become dead code effectively.
> 
It is still possible to create a vdpa device with a zero mac address
explicitly, right? 

>         } else if ((add_config->mask & BIT_ULL(VDPA_ATTR_DEV_FEATURES)) == 0) {
>                 /*
>                  * We used to clear _F_MAC feature bit if seeing
>                  * zero mac address when device features are not
>                  * specifically provisioned. Keep the behaviour
>                  * so old scripts do not break.
>                  */
>                 device_features &= ~BIT_ULL(VIRTIO_NET_F_MAC);
> 
> If we are not going to honor old behaviour any more, looks to me we should also block users from creating vdpa device with zero mac address, if the mac attribute is specified. There's more sorrow than help the zero mac address could buy for users.
That makes sense. There is a small risk of breaking user's scripts that
do this by accident...

Thanks,
Dragos

      reply	other threads:[~2024-08-28  7:53 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-27 16:02 Dragos Tatulea
2024-08-27 20:43 ` Nelson, Shannon
2024-08-28  1:50 ` Jason Wang
2024-08-28  9:00   ` Cindy Lu
2024-08-28  9:37     ` Dragos Tatulea
2024-08-29  9:05       ` Cindy Lu
2024-08-29 10:00         ` Dragos Tatulea
2024-08-29 19:03           ` Dragos Tatulea
2024-08-30  9:29             ` Cindy Lu
2024-08-30  9:43               ` Dragos Tatulea
2024-09-01 18:49               ` Michael S. Tsirkin
2024-09-02  9:55                 ` Cindy Lu
2024-08-30  9:12           ` Cindy Lu
2024-08-30 13:52             ` Dragos Tatulea
2024-08-30 14:46               ` Dragos Tatulea
2024-09-02  8:40                 ` Cindy Lu
2024-09-02  8:53                   ` Dragos Tatulea
2024-09-02  9:05                     ` Cindy Lu
2024-09-02  9:10                     ` Dragos Tatulea
2024-08-28  5:54 ` Si-Wei Liu
2024-08-28  7:53   ` Dragos Tatulea [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=5b99338f-56f7-492c-8a85-520badc28518@nvidia.com \
    --to=dtatulea@nvidia.com \
    --cc=eperezma@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=jiri@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=si-wei.liu@oracle.com \
    --cc=virtualization@lists.linux.dev \
    --cc=xuanzhuo@linux.alibaba.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

all inboxes | Powered by JetHome®