From: Maxime Coquelin <maxime.coquelin@redhat.com>
To: "Wang, Xiao W" <xiao.w.wang@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: "Wang, Zhihong" <zhihong.wang@intel.com>,
"yliu@fridaylinux.org" <yliu@fridaylinux.org>,
"Liang, Cunming" <cunming.liang@intel.com>,
"Xu, Rosen" <rosen.xu@intel.com>,
"Chen, Junjie J" <junjie.j.chen@intel.com>,
"Daly, Dan" <dan.daly@intel.com>
Subject: Re: [dpdk-dev] [PATCH 0/3] add ifcvf driver
Date: Tue, 27 Mar 2018 07:09:41 +0200 [thread overview]
Message-ID: <d439667f-c537-c3ca-caef-26bda1f36c88@redhat.com> (raw)
In-Reply-To: <B7F2E978279D1D49A3034B7786DACF406F857CCF@SHSMSX101.ccr.corp.intel.com>
Hi Xiao,
On 03/27/2018 06:40 AM, Wang, Xiao W wrote:
> Hi Maxime,
>
>> -----Original Message-----
>> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com]
>> Sent: Monday, March 26, 2018 9:30 PM
>> To: Wang, Xiao W <xiao.w.wang@intel.com>; dev@dpdk.org
>> Cc: Wang, Zhihong <zhihong.wang@intel.com>; yliu@fridaylinux.org; Liang,
>> Cunming <cunming.liang@intel.com>; Xu, Rosen <rosen.xu@intel.com>; Chen,
>> Junjie J <junjie.j.chen@intel.com>; Daly, Dan <dan.daly@intel.com>
>> Subject: Re: [PATCH 0/3] add ifcvf driver
>>
>>
>>
>> On 03/26/2018 11:05 AM, Wang, Xiao W wrote:
>>> Hi Maxime,
>>>
>>>> -----Original Message-----
>>>> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com]
>>>> Sent: Sunday, March 25, 2018 5:51 PM
>>>> To: Wang, Xiao W <xiao.w.wang@intel.com>; dev@dpdk.org
>>>> Cc: Wang, Zhihong <zhihong.wang@intel.com>; yliu@fridaylinux.org; Liang,
>>>> Cunming <cunming.liang@intel.com>; Xu, Rosen <rosen.xu@intel.com>;
>> Chen,
>>>> Junjie J <junjie.j.chen@intel.com>; Daly, Dan <dan.daly@intel.com>
>>>> Subject: Re: [PATCH 0/3] add ifcvf driver
>>>>
>>>>
>>>>
>>>> On 03/23/2018 11:27 AM, Wang, Xiao W wrote:
>>>>> Hi Maxime,
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com]
>>>>>> Sent: Thursday, March 22, 2018 4:48 AM
>>>>>> To: Wang, Xiao W <xiao.w.wang@intel.com>; dev@dpdk.org
>>>>>> Cc: Wang, Zhihong <zhihong.wang@intel.com>; yliu@fridaylinux.org;
>> Liang,
>>>>>> Cunming <cunming.liang@intel.com>; Xu, Rosen <rosen.xu@intel.com>;
>>>> Chen,
>>>>>> Junjie J <junjie.j.chen@intel.com>; Daly, Dan <dan.daly@intel.com>
>>>>>> Subject: Re: [PATCH 0/3] add ifcvf driver
>>>>>>
>>>>>> Hi Xiao,
>>>>>>
>>>>>> On 03/15/2018 05:49 PM, Wang, Xiao W wrote:
>>>>>>> Hi Maxime,
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com]
>>>>>>>> Sent: Sunday, March 11, 2018 2:24 AM
>>>>>>>> To: Wang, Xiao W <xiao.w.wang@intel.com>; dev@dpdk.org
>>>>>>>> Cc: Wang, Zhihong <zhihong.wang@intel.com>; yliu@fridaylinux.org;
>>>> Liang,
>>>>>>>> Cunming <cunming.liang@intel.com>; Xu, Rosen
>> <rosen.xu@intel.com>;
>>>>>> Chen,
>>>>>>>> Junjie J <junjie.j.chen@intel.com>; Daly, Dan <dan.daly@intel.com>
>>>>>>>> Subject: Re: [PATCH 0/3] add ifcvf driver
>>>>>>>>
>>>>>>>> Hi Xiao,
>>>>>>>>
>>>>>>>> On 03/10/2018 12:08 AM, Xiao Wang wrote:
>>>>>>>>> This patch set has dependency on
>>>>>>>> http://dpdk.org/dev/patchwork/patch/35635/
>>>>>>>>> (vhost: support selective datapath);
>>>>>>>>>
>>>>>>>>> ifc VF is compatible with virtio vring operations, this driver
>> implements
>>>>>>>>> vDPA driver ops which configures ifc VF to be a vhost data path
>>>> accelerator.
>>>>>>>>>
>>>>>>>>> ifcvf driver uses vdev as a control domain to manage ifc VFs that
>> belong
>>>>>>>>> to it. It registers vDPA device ops to vhost lib to enable these VFs to
>> be
>>>>>>>>> used as vhost data path accelerator.
>>>>>>>>>
>>>>>>>>> Live migration feature is supported by ifc VF and this driver enables
>>>>>>>>> it based on vhost lib.
>>>>>>>>>
>>>>>>>>> vDPA needs to create different containers for different devices, thus
>> this
>>>>>>>>> patch set adds APIs in eal/vfio to support multiple container.
>>>>>>>> Thanks for this! That will avoind having to duplicate these functions
>>>>>>>> for every new offload driver.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Junjie Chen (1):
>>>>>>>>> eal/vfio: add support for multiple container
>>>>>>>>>
>>>>>>>>> Xiao Wang (2):
>>>>>>>>> bus/pci: expose sysfs parsing API
>>>>>>>>
>>>>>>>> Still, I'm not convinced the offload device should be a virtual device.
>>>>>>>> It is a real PCI device, why not having a new device type for offload
>>>>>>>> devices, and let the device to be probed automatically by the existing
>>>>>>>> device model?
>>>>>>>
>>>>>>> IFC VFs are generated from SRIOV, with the PF driven by kernel driver.
>>>>>>> In DPDK we need to have something to represent PF, to register itself as
>>>>>>> a vDPA engine, so a virtual device is used for this purpose.
>>>>>> I went through the code, and something is not clear to me.
>>>>>>
>>>>>> Why do we need to have a representation of the PF in DPDK?
>>>>>> Why cannot we just bind at VF level?
>>>>>
>>>>> 1. With the vdev representation we could use it to talk to PF kernel driver
>> to
>>>> do flow configuration, we can implement
>>>>> flow API on the vdev in future for this purpose. Using a vdev allows
>>>> introducing this kind of control plane thing.
>>>>>
>>>>> 2. When port representor is ready, we would integrate it into ifcvf driver,
>>>> then each VF will have a
>>>>> Representor port. For now we don’t have port representor, so this patch
>> set
>>>> manages VF resource internally.
>>>>
>>>> Ok, we may need to have a vdev to represent the PF, but we need to be
>>>> able to bind at VF level anyway.
>>>
>>> Device management on VF level is feasible, according to the previous port-
>> representor patch.
>>> A tuple of (PF_addr, VF_index) can identify a certain VF, we have vport_mask
>>> and device addr to describe a PF, and we can specify a VF index to create a
>> representor port,
>>> so , the VF port creation will be on-demand at VF level.
>>>
>>> +struct port_rep_parameters {
>>> + uint64_t vport_mask;
>>> + struct {
>>> + char bus[RTE_DEV_NAME_MAX_LEN];
>>> + char device[RTE_DEV_NAME_MAX_LEN];
>>> + } parent;
>>> +};
>>>
>>> +int
>>> +rte_representor_port_register(char *pf_addr_str,
>>> + uint32_t vport_id, uint16_t *port_id)
>>
>> IIUC, even with this using port representor, we'll still have the
>> problem of having the VFs probed first as Virtio driver, right?
>>
>> In my opinion, the IFCVF devices in offload mode are to be managed
>> differently than having a way to represent on host side VFs assigned to
>> a VM.
>>
>> In offload case, you have a real device to deal with, else we
>> wouldn't have to bind it with VFIO.
>>
>> Maybe we could have a real device probed as proposed yesterday [0], and
>> this device gets registered to the port representor for the PF?
>
> Adding a list of offload-device in eal is a way to skip virtio pmd probe [0].
> I think using device devargs could also achieve that: add a parameter "vdpa=1"
> to the device, virtio pmd parses the devargs and detects that the device is in vdpa mode,
> quits its probe immediately.
> Devargs could be flexible of allowing one device with multi driver case.
That's a good idea, but if we want the vDPA VF to probed in a generic
way, will it work? I think the Virtio PMD won't be probed but no other
driver will be tried, but I might be wrong.
Thanks,
Maxime
> BRs,
> Xiao
>
>>
>> Thanks,
>> Maxime
>>> Besides, IFCVF supports live migration, vDPA exerts IFCVF device better than
>> QEMU (this patch has enabled LM feature).
>>> vDPA is the main usage model for IFCVF, and one DPDK application taking
>> control of all the VF resource
>>> management is a straightforward usage model.
>>>
>>> Best Regards,
>>> Xiao
>>>
>>>>
>>>> Else, how do you support passing two VFs of the same PF to different
>>>> DPDK applications?
>>>> Or have some VFs managed by Kernel or QEMU and some by the DPDK
>>>> application? My feeling is that current implementation is creating an
>>>> artificial constraint.
>>>>
>>>> Isn't there a possibility to have the virtual representation for the PF
>>>> to be probed separately? Or created automatically when the first VF of a
>>>> PF is probed (and later VFs attach to the PF rep when probed)?
>>>>
>>>> Doing this, we could use the generic device probing.
>>
>> [0]:
>>>> For IFCVF, to specify we want it to be probed as an offload device
>>>> instead of a virtio device, we could have a new EAL parameter to specify
>>>> for a given device if we want it to be probed as an offload device (for
>>>> example --offload=00:01.1).
>>>> Offload drivers would register by passing a flag that specifies they are
>>>> an offload driver.
>>>> This new argument would be optional and only used to force the device to
>>>> being probed in offload mode. For devices that have their own device
>>>> IDs for offload mode, then it would be automatic.
>>>>
>>>> Regards,
>>>> Maxime
>>>>> BRs,
>>>>> Xiao
>>>>>
prev parent reply other threads:[~2018-03-27 5:09 UTC|newest]
Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-09 23:08 Xiao Wang
2018-03-09 23:08 ` [dpdk-dev] [PATCH 1/3] eal/vfio: add support for multiple container Xiao Wang
2018-03-14 12:08 ` Burakov, Anatoly
2018-03-15 16:49 ` Wang, Xiao W
2018-03-09 23:08 ` [dpdk-dev] [PATCH 2/3] bus/pci: expose sysfs parsing API Xiao Wang
2018-03-14 11:19 ` Burakov, Anatoly
2018-03-14 13:30 ` Gaëtan Rivet
2018-03-15 16:49 ` Wang, Xiao W
2018-03-15 17:19 ` Gaëtan Rivet
2018-03-19 1:31 ` Wang, Xiao W
2018-03-21 13:21 ` [dpdk-dev] [PATCH v2 0/3] add ifcvf driver Xiao Wang
2018-03-21 13:21 ` [dpdk-dev] [PATCH v2 1/3] eal/vfio: add support for multiple container Xiao Wang
2018-03-21 20:32 ` Thomas Monjalon
2018-03-21 21:37 ` Gaëtan Rivet
2018-03-22 3:00 ` Wang, Xiao W
2018-03-21 13:21 ` [dpdk-dev] [PATCH v2 2/3] bus/pci: expose sysfs parsing API Xiao Wang
2018-03-21 20:44 ` Thomas Monjalon
2018-03-22 2:46 ` Wang, Xiao W
2018-03-21 13:21 ` [dpdk-dev] [PATCH v2 3/3] net/ifcvf: add ifcvf driver Xiao Wang
2018-03-21 20:52 ` Thomas Monjalon
2018-03-23 10:39 ` Wang, Xiao W
2018-03-21 20:57 ` Maxime Coquelin
2018-03-23 10:37 ` Wang, Xiao W
2018-03-22 8:51 ` Ferruh Yigit
2018-03-22 17:23 ` Wang, Xiao W
2018-03-31 2:29 ` [dpdk-dev] [PATCH v3 0/3] add ifcvf vdpa driver Xiao Wang
2018-03-31 2:29 ` [dpdk-dev] [PATCH v3 1/4] eal/vfio: add support for multiple container Xiao Wang
2018-03-31 11:06 ` Maxime Coquelin
2018-03-31 2:29 ` [dpdk-dev] [PATCH v3 2/4] net/virtio: skip device probe in vdpa mode Xiao Wang
2018-03-31 11:13 ` Maxime Coquelin
2018-03-31 13:16 ` Thomas Monjalon
2018-04-02 4:08 ` Wang, Xiao W
2018-03-31 2:29 ` [dpdk-dev] [PATCH v3 3/4] net/ifcvf: add ifcvf vdpa driver Xiao Wang
2018-03-31 11:26 ` Maxime Coquelin
2018-04-03 9:38 ` Wang, Xiao W
2018-04-04 14:40 ` [dpdk-dev] [PATCH v4 0/4] " Xiao Wang
2018-04-04 14:40 ` [dpdk-dev] [PATCH v4 1/4] eal/vfio: add multiple container support Xiao Wang
2018-04-05 18:06 ` [dpdk-dev] [PATCH v5 0/4] add ifcvf vdpa driver Xiao Wang
2018-04-05 18:06 ` [dpdk-dev] [PATCH v5 1/4] eal/vfio: add multiple container support Xiao Wang
2018-04-05 18:06 ` [dpdk-dev] [PATCH v5 2/4] net/virtio: skip device probe in vdpa mode Xiao Wang
2018-04-11 18:58 ` Ferruh Yigit
2018-04-05 18:07 ` [dpdk-dev] [PATCH v5 3/4] net/ifcvf: add ifcvf vdpa driver Xiao Wang
2018-04-11 18:58 ` Ferruh Yigit
2018-04-12 7:19 ` [dpdk-dev] [PATCH v6 0/4] " Xiao Wang
2018-04-12 7:19 ` [dpdk-dev] [PATCH v6 1/4] eal/vfio: add multiple container support Xiao Wang
2018-04-12 14:03 ` Burakov, Anatoly
2018-04-12 16:07 ` Wang, Xiao W
2018-04-12 16:24 ` Burakov, Anatoly
2018-04-13 9:18 ` Wang, Xiao W
2018-04-15 15:33 ` [dpdk-dev] [PATCH v7 0/5] add ifcvf vdpa driver Xiao Wang
2018-04-15 15:33 ` [dpdk-dev] [PATCH v7 1/5] vfio: extend data structure for multi container Xiao Wang
2018-04-16 10:02 ` Burakov, Anatoly
2018-04-16 12:22 ` Wang, Xiao W
2018-04-16 15:34 ` [dpdk-dev] [PATCH v8 0/5] add ifcvf vdpa driver Xiao Wang
2018-04-16 15:34 ` [dpdk-dev] [PATCH v8 1/5] vfio: extend data structure for multi container Xiao Wang
2018-04-16 15:56 ` Burakov, Anatoly
2018-04-16 15:34 ` [dpdk-dev] [PATCH v8 2/5] vfio: add multi container support Xiao Wang
2018-04-16 15:58 ` Burakov, Anatoly
2018-04-17 7:06 ` [dpdk-dev] [PATCH v9 0/5] add ifcvf vdpa driver Xiao Wang
2018-04-17 7:06 ` [dpdk-dev] [PATCH v9 1/5] vfio: extend data structure for multi container Xiao Wang
2018-04-17 7:06 ` [dpdk-dev] [PATCH v9 2/5] vfio: add multi container support Xiao Wang
2018-04-17 7:06 ` [dpdk-dev] [PATCH v9 3/5] net/virtio: skip device probe in vdpa mode Xiao Wang
2018-04-17 7:06 ` [dpdk-dev] [PATCH v9 4/5] net/ifcvf: add ifcvf vdpa driver Xiao Wang
2018-04-17 7:06 ` [dpdk-dev] [PATCH v9 5/5] doc: add ifcvf driver document and release note Xiao Wang
2018-04-17 11:13 ` [dpdk-dev] [PATCH v9 0/5] add ifcvf vdpa driver Ferruh Yigit
2018-04-16 15:34 ` [dpdk-dev] [PATCH v8 3/5] net/virtio: skip device probe in vdpa mode Xiao Wang
2018-04-16 15:34 ` [dpdk-dev] [PATCH v8 4/5] net/ifcvf: add ifcvf vdpa driver Xiao Wang
2018-04-16 15:34 ` [dpdk-dev] [PATCH v8 5/5] doc: add ifcvf driver document and release note Xiao Wang
2018-04-16 16:36 ` [dpdk-dev] [PATCH v8 0/5] add ifcvf vdpa driver Ferruh Yigit
2018-04-16 18:07 ` Thomas Monjalon
2018-04-17 5:36 ` Wang, Xiao W
2018-04-15 15:33 ` [dpdk-dev] [PATCH v7 2/5] vfio: add multi container support Xiao Wang
2018-04-16 10:03 ` Burakov, Anatoly
2018-04-16 12:44 ` Wang, Xiao W
2018-04-15 15:33 ` [dpdk-dev] [PATCH v7 3/5] net/virtio: skip device probe in vdpa mode Xiao Wang
2018-04-15 15:33 ` [dpdk-dev] [PATCH v7 4/5] net/ifcvf: add ifcvf vdpa driver Xiao Wang
2018-04-15 15:33 ` [dpdk-dev] [PATCH v7 5/5] doc: add ifcvf driver document and release note Xiao Wang
2018-04-12 7:19 ` [dpdk-dev] [PATCH v6 2/4] net/virtio: skip device probe in vdpa mode Xiao Wang
2018-04-12 7:19 ` [dpdk-dev] [PATCH v6 3/4] net/ifcvf: add ifcvf vdpa driver Xiao Wang
2018-04-12 7:19 ` [dpdk-dev] [PATCH v6 4/4] doc: add ifcvf driver document and release note Xiao Wang
2018-04-05 18:07 ` [dpdk-dev] [PATCH v5 " Xiao Wang
2018-04-11 18:59 ` [dpdk-dev] [PATCH v5 0/4] add ifcvf vdpa driver Ferruh Yigit
2018-04-12 5:47 ` Wang, Xiao W
2018-04-04 14:40 ` [dpdk-dev] [PATCH v4 2/4] net/virtio: skip device probe in vdpa mode Xiao Wang
2018-04-04 14:40 ` [dpdk-dev] [PATCH v4 3/4] net/ifcvf: add ifcvf vdpa driver Xiao Wang
2018-04-04 14:40 ` [dpdk-dev] [PATCH v4 4/4] doc: add ifcvf driver document and release note Xiao Wang
2018-03-31 2:29 ` [dpdk-dev] [PATCH v3 4/4] net/ifcvf: add " Xiao Wang
2018-03-31 11:28 ` Maxime Coquelin
2018-03-09 23:08 ` [dpdk-dev] [PATCH 3/3] net/ifcvf: add ifcvf driver Xiao Wang
2018-03-10 18:23 ` [dpdk-dev] [PATCH 0/3] " Maxime Coquelin
2018-03-15 16:49 ` Wang, Xiao W
2018-03-21 20:47 ` Maxime Coquelin
2018-03-23 10:27 ` Wang, Xiao W
2018-03-25 9:51 ` Maxime Coquelin
2018-03-26 9:05 ` Wang, Xiao W
2018-03-26 13:29 ` Maxime Coquelin
2018-03-27 4:40 ` Wang, Xiao W
2018-03-27 5:09 ` 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=d439667f-c537-c3ca-caef-26bda1f36c88@redhat.com \
--to=maxime.coquelin@redhat.com \
--cc=cunming.liang@intel.com \
--cc=dan.daly@intel.com \
--cc=dev@dpdk.org \
--cc=junjie.j.chen@intel.com \
--cc=rosen.xu@intel.com \
--cc=xiao.w.wang@intel.com \
--cc=yliu@fridaylinux.org \
--cc=zhihong.wang@intel.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;
as well as URLs for NNTP newsgroup(s).