[dpdk-dev] [PATCH v3 02/10] vdpa/sfc: add support for device initialization

[Vijay Kumar Srivastava]

Hi Chenbo,

>-----Original Message-----
>From: Xia, Chenbo <chenbo.xia at intel.com>
>Sent: Tuesday, November 2, 2021 10:47 AM
>To: Vijay Kumar Srivastava <vsrivast at xilinx.com>; dev at dpdk.org
>Cc: maxime.coquelin at redhat.com; andrew.rybchenko at oktetlabs.ru; Praveen
>Kumar Jain <praveenj at xilinx.com>
>Subject: RE: [PATCH v3 02/10] vdpa/sfc: add support for device initialization
>
>> -----Original Message-----
>> From: Vijay Kumar Srivastava <vsrivast at xilinx.com>
>> Sent: Tuesday, November 2, 2021 12:38 PM
>> To: Xia, Chenbo <chenbo.xia at intel.com>; dev at dpdk.org
>> Cc: maxime.coquelin at redhat.com; andrew.rybchenko at oktetlabs.ru; Praveen
>> Kumar Jain <praveenj at xilinx.com>
>> Subject: RE: [PATCH v3 02/10] vdpa/sfc: add support for device
>> initialization
>>
>> Hi Chenbo,
>>
>> >-----Original Message-----
>> >From: Xia, Chenbo <chenbo.xia at intel.com>
>> >Sent: Monday, November 1, 2021 5:19 PM
>> >To: Vijay Kumar Srivastava <vsrivast at xilinx.com>; dev at dpdk.org
>> >Cc: maxime.coquelin at redhat.com; andrew.rybchenko at oktetlabs.ru; Vijay
>> >Kumar Srivastava <vsrivast at xilinx.com>
>> >Subject: RE: [PATCH v3 02/10] vdpa/sfc: add support for device
>> >initialization
>> >
>> >Hi Vijay,
>> >
>> >> -----Original Message-----
>> >> From: Vijay Srivastava <vijay.srivastava at xilinx.com>
>> >> Sent: Friday, October 29, 2021 10:47 PM
>> >> To: dev at dpdk.org
>> >> Cc: maxime.coquelin at redhat.com; Xia, Chenbo <chenbo.xia at intel.com>;
>> >> andrew.rybchenko at oktetlabs.ru; Vijay Kumar Srivastava
>> >> <vsrivast at xilinx.com>
>> >> Subject: [PATCH v3 02/10] vdpa/sfc: add support for device
>> >> initialization
>> >>
>> >> From: Vijay Kumar Srivastava <vsrivast at xilinx.com>
>> >>
>> >> Add HW initialization and vDPA device registration support.
>> >>
>> >> Signed-off-by: Vijay Kumar Srivastava <vsrivast at xilinx.com>
>> >> Acked-by: Andrew Rybchenko <andrew.rybchenko at oktetlabs.ru>
>> >> ---
>> [SNIP]
>> >> +
>> >> +	do {
>> >> +		ret = rte_vfio_container_dma_map(sva->vfio_container_fd,
>> >> +						 (uint64_t)mz->addr,
>> >mcdi_iova,
>> >> +						 mcdi_buff_size);
>> >> +		if (ret == 0)
>> >> +			break;
>> >> +
>> >> +		mcdi_iova = mcdi_iova >> 1;
>> >> +		if (mcdi_iova < mcdi_buff_size)	{
>> >> +			sfc_vdpa_err(sva,
>> >> +				     "DMA mapping failed for MCDI : %s",
>> >> +				     rte_strerror(rte_errno));
>> >> +			rte_memzone_free(mz);
>> >> +			return ret;
>> >> +		}
>> >> +
>> >> +	} while (ret < 0);
>> >
>> >So when QEMU iova and mcdi_iova conflicts, you just let vdpa dev
>> >failed to configure, right?
>> >
>> >Why not use re-mapping mcdi dma region as the solution? Any side-effect?
>> >Or you just assume conflict can hardly happen?
>>
>> MCDI configuration is being done at the very early point of initialization.
>> Conflict would be detected later when rte_vhost_get_mem_table() would
>> be invoked in .dev_conf callback and then MCDI re-mapping can be done
>> in case of conflict,
>
>Agree. It should be done in dev_conf callback.
>
>> for this a patch is in
>> progress which would be submitted separately.
>
>OK for me, as the initial version, you can just let dev_conf fail if conflict
>happens.
Yes. In case of conflict dev_conf would fail. 

Regards,
Vijay

>> [SNIP]