> -----Original Message----- > From: Ferruh Yigit <ferruh.yi...@intel.com> > Sent: Monday, July 20, 2020 18:26 > To: Slava Ovsiienko <viachesl...@mellanox.com>; dev@dpdk.org > Cc: Matan Azrad <ma...@mellanox.com>; Raslan Darawsheh > <rasl...@mellanox.com>; olivier.m...@6wind.com; Thomas Monjalon > <tho...@monjalon.net>; David Marchand <david.march...@redhat.com>; > Phil Yang <phil.y...@arm.com>; Ruifeng Wang <ruifeng.w...@arm.com>; > Honnappa Nagarahalli <honnappa.nagaraha...@arm.com> > Subject: Re: [dpdk-dev] [PATCH v3 07/17] net/mlx5: create Tx queues with > DevX > > On 7/20/2020 3:18 PM, Ferruh Yigit wrote: > > On 7/16/2020 9:23 AM, Viacheslav Ovsiienko wrote: > >> To provide the packet send schedule on mbuf timestamp the Tx queue > >> must be attached to the same UAR as Clock Queue is. > >> UAR is special hardware related resource mapped to the host memory > >> and provides doorbell registers, the assigning UAR to the queue being > >> created is provided via DevX API only. > >> > >> Signed-off-by: Viacheslav Ovsiienko <viachesl...@mellanox.com> > >> Acked-by: Matan Azrad <ma...@mellanox.com> > > > > <...> > > > >> + MLX5_ASSERT(sh->tx_uar); > >> + MLX5_ASSERT(sh->tx_uar->reg_addr); > >> + txq_ctrl->bf_reg = sh->tx_uar->reg_addr; > >> + txq_ctrl->uar_mmap_offset = sh->tx_uar->mmap_off; > >> + rte_atomic32_set(&txq_obj->refcnt, 1); > > > > This is using a function we plan to deprecate in long term, and > > checkpatch has a warning for it [1]. > > > > To prevent this being blocker, I will preceed with the patchset and > > can you please send an increamental patch to fix it, I can squash it before > > - > rc2. > > > > Thanks, > > ferruh > > > > > > [1] > > Warning in drivers/net/mlx5/mlx5_txq.c: > > Using rte_atomicNN_xxx > > > > cc'ed Honnapa too, from techboard discussion [2] I understand we won't > accept new code with old API. But also to be fair the check was not there > until last week so this was easy to miss by developers. > > @Slava, can you please do your best to replace them before the release? > Perhaps @Honnappa can support on the effort?
> And if this can't be done withing the release not sure what to do, one option > is to get them with the commitment from Mellanox to fix this on 20.11? I try to do the best before the release personally, but not sure we can pass the full testing/verification cycle. So, I suppose to take the commitment to fix it on 20.11 (there is no other way due to "atomic" deprecation). If we have the update before 20.08rc3, we'll push it. With best regards, Slava > > [2] > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmails. > dpdk.org%2Farchives%2Fdev%2F2020- > April%2F165143.html&data=02%7C01%7Cviacheslavo%40mellanox.co > m%7Cea28f4d3c667404c4cdd08d82cc137fe%7Ca652971c7d2e4d9ba6a4d14 > 9256f461b%7C0%7C0%7C637308555673206316&sdata=iNXzvMc%2FPh > TnrLuW52F9z2t0bag9%2Ftw7AOTxwp8rkfI%3D&reserved=0
