All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxime Coquelin <maxime.coquelin@redhat.com>
To: Adrian Moreno <amorenoz@redhat.com>,
	dev@dpdk.org, chenbo.xia@intel.com, david.marchand@redhat.com
Subject: Re: [dpdk-dev] [RFC 0/3] net/virtio: add vdpa device config support
Date: Fri, 16 Apr 2021 10:10:17 +0200	[thread overview]
Message-ID: <a9471e7b-3b32-8357-1fab-f77872b9763c@redhat.com> (raw)
In-Reply-To: <bfa125f6-6426-6c4c-c197-80959d99a8df@redhat.com>

Hi Adrian,

Thanks for your feedback.

On 4/16/21 9:28 AM, Adrian Moreno wrote:
> 
> 
> On 3/18/21 11:35 PM, Maxime Coquelin wrote:
>> This patch adds vDPA device config space requests support.
>> For now, it only adds MAC address get and set. It may be
>> extended in next revision to support other configs like
>> link state.
>>
>> Regarding the MAC selection strategy, if devargs MAC address
>> is set by the user and valid, the driver tries to store it
>> in the device config space, then it reads the MAC address
>> back from the device config, which will be used. If not set
>> in devargs or invalid, it tries to read it from the device.
>> If it fails, a random MAC will be used.
>>
>> I'm interrested to know your feedback on this strategy.
> 
> In general, I think it's a reasonable strategy. Once we have cq support, things
> will be a bit easier.
> 
> Some questions:
> How should we interpret failure to configure the mac (i.e: after set and get,
> they still don't match)? Should we fail virtio_user_dev_init if the
> configuration provided by devargs is not successfully applied?
> 
> Should a zero mac be treated differntly as qemu does? [1]
> 
> [1]
> https://patchwork.ozlabs.org/project/qemu-devel/patch/20210302142014.141135-3-mst@redhat.com/

Testing with ConnectX-6 Dx, I can see that the device does not advertise
VIRTIO_NET_F_MAC, so with this is series, it just doesn't try to read it
from the device.

My understanding is that in Qemu, the feature is forced[0], which
explains why it reads zeroes.

> 
>> It has been tested with vDPA simulator, which only supports
>> getting the MAC address, and witch CX6 which supports neither
>> getting or setting MAC address (and so devarg or random MAC is
>> used). IFCVF driver seems to support both getting and setting
>> the MAC, I have a try with it before next revision.
> 
> Does cx6 negotiate VIRTIO_NET_F_MAC?

Nope.
I haven't tested yet with IFCVF.

Maxime

>>
>> Maxime Coquelin (3):
>>   net/virtio: keep device and frontend features separated
>>   net/virtio: add device config support to vDPA
>>   net/virtio: add MAC device config getter and setter
>>
>>  drivers/net/virtio/virtio_user/vhost.h        |  3 +
>>  drivers/net/virtio/virtio_user/vhost_vdpa.c   | 69 +++++++++++++++
>>  .../net/virtio/virtio_user/virtio_user_dev.c  | 88 +++++++++++++++----
>>  .../net/virtio/virtio_user/virtio_user_dev.h  |  2 +
>>  drivers/net/virtio/virtio_user_ethdev.c       | 12 ++-
>>  5 files changed, 151 insertions(+), 23 deletions(-)
>>
> 

[0]: https://elixir.bootlin.com/qemu/latest/source/hw/net/virtio-net.c#L3078


      reply	other threads:[~2021-04-16  8:10 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
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 [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=a9471e7b-3b32-8357-1fab-f77872b9763c@redhat.com \
    --to=maxime.coquelin@redhat.com \
    --cc=amorenoz@redhat.com \
    --cc=chenbo.xia@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.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.