Thanks for your comment and will fix it on V3. Regards, Li Zhang
> -----Original Message----- > From: Maxime Coquelin <[email protected]> > Sent: Friday, June 17, 2022 11:37 PM > To: Li Zhang <[email protected]>; Ori Kam <[email protected]>; Slava > Ovsiienko <[email protected]>; Matan Azrad <[email protected]>; > Shahaf Shuler <[email protected]> > Cc: [email protected]; NBU-Contact-Thomas Monjalon (EXTERNAL) > <[email protected]>; Raslan Darawsheh <[email protected]>; Roni > Bar Yanai <[email protected]>; Yajun Wu <[email protected]> > Subject: Re: [PATCH v2 02/15] vdpa/mlx5: support pre create virtq resource > > External email: Use caution opening links or attachments > > > On 6/16/22 04:29, Li Zhang wrote: > > From: Yajun Wu <[email protected]> > > > > The motivation of this change is to reduce vDPA device queue creation > > time by create some queue resource in vDPA device probe stage. > > s/create/creating/ > > > > > In VM live migration scenario, this can reduce 0.8ms for each queue > > creation, thus reduce LM network downtime. > > > > To create queue resource(umem/counter) in advance, we need to know > > virtio queue depth and max number of queue VM will use. > > > > Introduce two new devargs: queues(max queue pair number) and > > queue_size (queue depth). Two args must be both provided, if only one > > argument provided, the argument will be ignored and no pre-creation. > > > > The queues and queue_size must also be identical to vhost > > configuration driver later receive. Otherwise either the pre-create > > resource is wasted or missing or the resource need destroy and > > recreate(in case queue_size mismatch). > > > > Pre-create umem/counter will keep alive until vDPA device removal. > > > > Signed-off-by: Yajun Wu <[email protected]> > > Acked-by: Matan Azrad <[email protected]> > > --- > > doc/guides/vdpadevs/mlx5.rst | 14 +++++++ > > drivers/vdpa/mlx5/mlx5_vdpa.c | 75 > ++++++++++++++++++++++++++++++++++- > > drivers/vdpa/mlx5/mlx5_vdpa.h | 2 + > > 3 files changed, 89 insertions(+), 2 deletions(-) > > > > Reviewed-by: Maxime Coquelin <[email protected]> > > Thanks, > Maxime
