All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxime Coquelin <mcoqueli@redhat.com>
To: "Xia, Chenbo" <chenbo.xia@intel.com>,
	Maxime Coquelin <maxime.coquelin@redhat.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	"amorenoz@redhat.com" <amorenoz@redhat.com>,
	"david.marchand@redhat.com" <david.marchand@redhat.com>
Subject: Re: [dpdk-dev] [RFC 3/3] net/virtio: add MAC device config getter and setter
Date: Tue, 8 Jun 2021 08:22:46 +0200	[thread overview]
Message-ID: <13284080-d812-8035-e403-73d1160e8f05@redhat.com> (raw)
In-Reply-To: <MN2PR11MB406351D59F0C6D6D2112DAE99C379@MN2PR11MB4063.namprd11.prod.outlook.com>



On 6/8/21 7:29 AM, Xia, Chenbo wrote:
> Hi Maxime,
> 
>> -----Original Message-----
>> From: Maxime Coquelin <mcoqueli@redhat.com>
>> Sent: Thursday, June 3, 2021 10:29 PM
>> To: Xia, Chenbo <chenbo.xia@intel.com>; Maxime Coquelin
>> <maxime.coquelin@redhat.com>; dev@dpdk.org; amorenoz@redhat.com;
>> david.marchand@redhat.com
>> Subject: Re: [RFC 3/3] net/virtio: add MAC device config getter and setter
>>
>> Hi Chenbo,
>>
>> On 4/19/21 8:24 AM, Xia, Chenbo wrote:
>>> Hi Maxime,
>>>
>>>> -----Original Message-----
>>>> From: Maxime Coquelin <maxime.coquelin@redhat.com>
>>>> Sent: Friday, March 19, 2021 6:35 AM
>>>> To: dev@dpdk.org; Xia, Chenbo <chenbo.xia@intel.com>; amorenoz@redhat.com;
>>>> david.marchand@redhat.com
>>>> Cc: Maxime Coquelin <maxime.coquelin@redhat.com>
>>>> Subject: [RFC 3/3] net/virtio: add MAC device config getter and setter
>>>>
>>>> This patch uses the new device config ops to get and set
>>>> the MAC address if supported.
>>>>
>>>> If a valid MAC address is passed as devarg of the
>>>> Virtio-user PMD, the driver will try to store it in the
>>>> device config space. Otherwise the one provided in
>>>> the device config space will be used, if available.
>>>
>>> I agree with the MAC selection strategy you proposed.
>>>
>>>>
>>>> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
>>>> ---
>>>>  .../net/virtio/virtio_user/virtio_user_dev.c  | 78 ++++++++++++++++---
>>>>  .../net/virtio/virtio_user/virtio_user_dev.h  |  2 +
>>>>  drivers/net/virtio/virtio_user_ethdev.c       |  7 +-
>>>>  3 files changed, 74 insertions(+), 13 deletions(-)
>>>>
>>>> diff --git a/drivers/net/virtio/virtio_user/virtio_user_dev.c
>>>> b/drivers/net/virtio/virtio_user/virtio_user_dev.c
>>>> index 8757a23f6e..61517692b3 100644
>>>> --- a/drivers/net/virtio/virtio_user/virtio_user_dev.c
>>>> +++ b/drivers/net/virtio/virtio_user/virtio_user_dev.c
>>>> @@ -259,20 +259,76 @@ int virtio_user_stop_device(struct virtio_user_dev
>> *dev)
>>>>  	return -1;
>>>>  }
>>>>
>>>> -static inline void
>>>> -parse_mac(struct virtio_user_dev *dev, const char *mac)
>>>> +int
>>>> +virtio_user_dev_set_mac(struct virtio_user_dev *dev)
>>>>  {
>>>> -	struct rte_ether_addr tmp;
>>>> +	int ret = 0;
>>>>
>>>> -	if (!mac)
>>>> -		return;
>>>> +	if (!(dev->device_features & (1ULL << VIRTIO_NET_F_MAC)))
>>>> +		return -ENOTSUP;
>>>> +
>>>> +	if (!dev->ops->set_config)
>>>> +		return -ENOTSUP;
>>>> +
>>>> +	ret = dev->ops->set_config(dev, dev->mac_addr,
>>>> +			offsetof(struct virtio_net_config, mac),
>>>> +			RTE_ETHER_ADDR_LEN);
>>>> +	if (ret)
>>>> +		PMD_DRV_LOG(ERR, "(%s) Failed to set MAC address in device\n",
>>>> dev->path);
>>>> +
>>>> +	return ret;
>>>> +}
>>>> +
>>>> +int
>>>> +virtio_user_dev_get_mac(struct virtio_user_dev *dev)
>>>> +{
>>>> +	int ret = 0;
>>>> +
>>>> +	if (!(dev->device_features & (1ULL << VIRTIO_NET_F_MAC)))
>>>> +		return -ENOTSUP;
>>>> +
>>>> +	if (!dev->ops->get_config)
>>>> +		return -ENOTSUP;
>>>> +
>>>> +	ret = dev->ops->get_config(dev, dev->mac_addr,
>>>> +			offsetof(struct virtio_net_config, mac),
>>>> +			RTE_ETHER_ADDR_LEN);
>>>> +	if (ret)
>>>> +		PMD_DRV_LOG(ERR, "(%s) Failed to get MAC address from device\n",
>>>> dev->path);
>>>>
>>>> -	if (rte_ether_unformat_addr(mac, &tmp) == 0) {
>>>> -		memcpy(dev->mac_addr, &tmp, RTE_ETHER_ADDR_LEN);
>>>> +	return ret;
>>>> +}
>>>> +
>>>> +static void
>>>> +virtio_user_dev_init_mac(struct virtio_user_dev *dev, const char *mac)
>>>> +{
>>>> +	struct rte_ether_addr cmdline_mac;
>>>> +	int ret;
>>>> +
>>>> +	if (mac && rte_ether_unformat_addr(mac, &cmdline_mac) == 0) {
>>>> +		/*
>>>> +		 * MAC address was passed from command-line, try to store
>>>> +		 * it in the device if it supports it. Otherwise try to use
>>>> +		 * the device one.
>>>> +		 */
>>>> +		memcpy(dev->mac_addr, &cmdline_mac, RTE_ETHER_ADDR_LEN);
>>>>  		dev->mac_specified = 1;
>>>
>>> How do we define mac_specified? If I understand correctly, it means the mac
>>> we see is from device (we set it or we just use device's). Then 'dev-
>>> mac_specified = 1'
>>> should be after get_mac succeeds.
>>
>> You are correct, mac_specified=1 means either user or device specified
>> MAC address. If get_mac fails below then we use the user specified MAC
>> address, so mac_specified = 1 is still valid in this case.
>>
>>> Note that during virtio_user_dev_init, we also use
>>> this val to set VIRTIO_NET_F_MAC. But here the val is set without making
>> sure the
>>> feature exists.
>>
>> I am not sure to get youre point, but it sets VIRTIO_NET_F_MAC in the
>> frontend features there, that does not mean the feature is negotiated in
>> the end.
> 
> I think you are correct, I may misunderstood something when I review this first
> time. And I want to make sure we are on the same page: since 'mac_specified=1'
> will set VIRTIO_NET_F_MAC in frontend_features, so only when user don't set mac
> and we don't get mac in device will lead to this feature unsupported, right?

Yes, correct. The idea was to keep the old behaviour, i.e. support it
when user specifies the MAC in the devargs, and extend it to support the
feature when the device can provide the MAC address.

Regards,
Maxime

>>
>>>> +
>>>> +		/* Setting MAC may fail, continue to get the device one in this
>>>> case */
>>>> +		virtio_user_dev_set_mac(dev);
>>>> +		ret = virtio_user_dev_get_mac(dev);
>>>> +		if (ret == -ENOTSUP)
>>>> +			return;
>>>> +
>>>> +		if (memcmp(&cmdline_mac, dev->mac_addr, RTE_ETHER_ADDR_LEN))
>>>> +			PMD_DRV_LOG(INFO, "(%s) Device MAC update failed\n", dev-
>>>>> path);
>>>
>>> Besides Adrian's comments, if we decide to return no error on this, it may
>> also
>>> be good to add something like 'using random MAC' to tell users that the
>> driver will
>>> use random mac. Adding here or in the function that generates mac is both ok.
>>
>> If it fails here, it won't be using a random MAC, but the MAC provided
>> by the user. The log could be improved with something like:
>> "Device MAC update failed, using MAC xx:xx:xx:xx:xx"
> 
> Yeah! That's good.
> 
> Thanks,
> Chenbo
> 
>>
>> What do you think?
>>
>>> The patchset overall looks good to me. I'm looking forward to v1 😊
>>>
>>> Thanks,
>>> Chenbo
>>
>> Thanks,
>> Maxime
> 


  reply	other threads:[~2021-06-08  6:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-18 22:35 [dpdk-dev] [RFC 0/3] net/virtio: add vdpa device config support Maxime Coquelin
2021-03-18 22:35 ` [dpdk-dev] [RFC 1/3] net/virtio: keep device and frontend features separated Maxime Coquelin
2021-03-18 22:35 ` [dpdk-dev] [RFC 2/3] net/virtio: add device config support to vDPA Maxime Coquelin
2021-03-18 22:35 ` [dpdk-dev] [RFC 3/3] net/virtio: add MAC device config getter and setter Maxime Coquelin
2021-04-16  9:27   ` Adrian Moreno
2021-04-19  6:24   ` Xia, Chenbo
2021-06-03 14:28     ` Maxime Coquelin
2021-06-08  5:29       ` Xia, Chenbo
2021-06-08  6:22         ` Maxime Coquelin [this message]
2021-04-16  7:28 ` [dpdk-dev] [RFC 0/3] net/virtio: add vdpa device config support Adrian Moreno
2021-04-16  8:10   ` Maxime Coquelin

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=13284080-d812-8035-e403-73d1160e8f05@redhat.com \
    --to=mcoqueli@redhat.com \
    --cc=amorenoz@redhat.com \
    --cc=chenbo.xia@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=maxime.coquelin@redhat.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 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.