[PATCH v7 12/18] vdpa/ifc: add some log at vDPA launch before qemu connect

Pei, Andy andy.pei at intel.com
Fri May 13 10:34:38 CEST 2022


Hi Chenbo,

Thanks for your reply.
My reply is inline.

> -----Original Message-----
> From: Xia, Chenbo <chenbo.xia at intel.com>
> Sent: Thursday, May 12, 2022 9:53 PM
> To: Pei, Andy <andy.pei at intel.com>; dev at dpdk.org
> Cc: maxime.coquelin at redhat.com; Cao, Gang <gang.cao at intel.com>; Liu,
> Changpeng <changpeng.liu at intel.com>
> Subject: RE: [PATCH v7 12/18] vdpa/ifc: add some log at vDPA launch before
> qemu connect
> 
> > -----Original Message-----
> > From: Pei, Andy <andy.pei at intel.com>
> > Sent: Wednesday, April 27, 2022 4:30 PM
> > To: dev at dpdk.org
> > Cc: Xia, Chenbo <chenbo.xia at intel.com>; maxime.coquelin at redhat.com;
> > Cao, Gang <gang.cao at intel.com>; Liu, Changpeng
> > <changpeng.liu at intel.com>
> > Subject: [PATCH v7 12/18] vdpa/ifc: add some log at vDPA launch before
> > qemu connect
> 
> Title can be:
> 
> vdpa/ifc: add log for config space of virtio blk
> 
Sure.
> >
> > Add some log of virtio blk device config space information at VDPA
> > launch before qemu connects.
> >
> > Signed-off-by: Andy Pei <andy.pei at intel.com>
> > ---
> >  drivers/vdpa/ifc/ifcvf_vdpa.c | 28 ++++++++++++++++++++++++++++
> >  1 file changed, 28 insertions(+)
> >
> > diff --git a/drivers/vdpa/ifc/ifcvf_vdpa.c
> > b/drivers/vdpa/ifc/ifcvf_vdpa.c index ca49bc3..4060a44 100644
> > --- a/drivers/vdpa/ifc/ifcvf_vdpa.c
> > +++ b/drivers/vdpa/ifc/ifcvf_vdpa.c
> > @@ -1363,6 +1363,9 @@ struct rte_vdpa_dev_info dev_info[] = {
> >  	struct rte_kvargs *kvlist = NULL;
> >  	int ret = 0;
> >  	int16_t device_id;
> > +	uint64_t capacity = 0;
> > +	uint8_t *byte;
> > +	uint32_t i;
> >
> >  	if (rte_eal_process_type() != RTE_PROC_PRIMARY)
> >  		return 0;
> > @@ -1429,6 +1432,31 @@ struct rte_vdpa_dev_info dev_info[] = {
> >  		internal->features = features &
> >  					~(1ULL <<
> VIRTIO_F_IOMMU_PLATFORM);
> >  		internal->features |= dev_info[IFCVF_BLK].features;
> > +
> > +		/* cannot read 64-bit register in one attempt,
> > +		 * so read byte by byte.
> > +		 */
> > +		for (i = 0; i < sizeof(internal->hw.blk_cfg->capacity); i++) {
> > +			byte = (uint8_t *)&internal->hw.blk_cfg->capacity + i;
> > +			capacity |= (uint64_t)*byte << (i * 8);
> > +		}
> > +		DRV_LOG(INFO, "capacity  : %"PRIu64"G", capacity >> 21);
> 
> I believe this '21' should be calculated rather than hard-code.
> 
/* The capacity (in 512-byte sectors). */
So right shift 1 we gwt in K. Another right shift 10 we get in M, right shift 10 more bits, we get in G.
10 + 10 + 1 = 21.
I think add some comments in code is fine, what do you think?

> And should these log all be debug log?
> 
These information is hardware ability. I think INFO is fine.

> Thanks,
> Chenbo
> 
> > +
> > +		DRV_LOG(INFO, "size_max  : 0x%08x",
> > +			internal->hw.blk_cfg->size_max);
> > +		DRV_LOG(INFO, "seg_max   : 0x%08x",
> > +			internal->hw.blk_cfg->seg_max);
> > +		DRV_LOG(INFO, "blk_size  : 0x%08x",
> > +			internal->hw.blk_cfg->blk_size);
> > +		DRV_LOG(INFO, "geometry");
> > +		DRV_LOG(INFO, "    cylinders: %u",
> > +			internal->hw.blk_cfg->geometry.cylinders);
> > +		DRV_LOG(INFO, "    heads    : %u",
> > +			internal->hw.blk_cfg->geometry.heads);
> > +		DRV_LOG(INFO, "    sectors  : %u",
> > +			internal->hw.blk_cfg->geometry.sectors);
> > +		DRV_LOG(INFO, "num_queues: 0x%08x",
> > +			internal->hw.blk_cfg->num_queues);
> >  	}
> >
> >  	list->internal = internal;
> > --
> > 1.8.3.1
> 



More information about the dev mailing list