On Mon, Jun 17, 2024 at 03:02:43PM +0200, Jiri Pirko wrote:

Mon, Jun 17, 2024 at 01:48:02PM CEST, parav@nvidia.com wrote:

quoted

quoted

From: Jiri Pirko <jiri@resnulli.us>
Sent: Monday, June 17, 2024 5:10 PM

Mon, Jun 17, 2024 at 11:44:53AM CEST, parav@nvidia.com wrote:

quoted

quoted

From: Jiri Pirko <jiri@resnulli.us>
Sent: Monday, June 17, 2024 3:09 PM

Mon, Jun 17, 2024 at 04:57:23AM CEST, parav@nvidia.com wrote:

quoted

quoted

From: Jason Wang <redacted>
Sent: Monday, June 17, 2024 7:18 AM

On Wed, Jun 12, 2024 at 2:30 PM Jiri Pirko [off-list ref] wrote:

quoted

Wed, Jun 12, 2024 at 03:58:10AM CEST, kuba@kernel.org wrote:

quoted

On Tue, 11 Jun 2024 13:32:32 +0800 Cindy Lu wrote:

quoted

Add new UAPI to support the mac address from vdpa tool
Function
vdpa_nl_cmd_dev_config_set_doit() will get the MAC address
from the vdpa tool and then set it to the device.

The usage is: vdpa dev set name vdpa_name mac
**:**:**:**:**:**

Why don't you use devlink?

Fair question. Why does vdpa-specific uapi even exist? To have
driver-specific uapi Does not make any sense to me :/

It came with devlink first actually, but switched to a dedicated uAPI.

Parav(cced) may explain more here.

Devlink configures function level mac that applies to all protocol
devices

(vdpa, rdma, netdev) etc.

quoted

Additionally, vdpa device level mac can be different (an additional
one) to

apply to only vdpa traffic.

quoted

Hence dedicated uAPI was added.

There is 1:1 relation between vdpa instance and devlink port, isn't it?
Then we have:
       devlink port function set DEV/PORT_INDEX hw_addr ADDR

Above command is privilege command done by the hypervisor on the port

function.

quoted

Vpda level setting the mac is similar to a function owner driver setting the

mac on the self netdev (even though devlink side has configured some mac for
it).

quoted

For example,
$ ip link set dev wlan1 address 00:11:22:33:44:55

Hmm, under what sceratio exacly this is needed?

The administrator on the host creating a vdpa device for the VM wants to configure the mac address for the VM.
This administrator may not have the access to the devlink port function.
Or he may just prefer a different MAC (theoretical case).

Right, but that is not reason for new uapi but rather reason to alter
existing devlink model to have the "host side". We discussed this many
times.

quoted

quoted

I mean, the VM that has VDPA device can actually do that too. 

VM cannot do. Virtio spec do not allow modifying the mac address.

I see. Any good reason to not allow that?

quoted

quoted

That is the actual function owner.

vdpa is not mapping a whole VF to the VM.
It is getting some synthetic PCI device composed using several software (kernel) and user space layers.
so VM is not the function owner.

Sure, but owner of the netdev side, to what the mac is related. That is
my point.

I don't know what this discussion is about, at this point.
For better or worse, vdpa gained interfaces for provisioning
new devices. Yes the solution space was wide but it's been there
for years so kind of too late to try and make people
move to another interface for that.

Having said that, vdpa interfaces are all built around
virtio spec. Let's try to stick to that.


-- 
MST