Hi Ferruh, > -----Original Message----- > From: Yigit, Ferruh <ferruh.yi...@intel.com> > Sent: Wednesday, September 1, 2021 12:01 AM > To: Ding, Xuan <xuan.d...@intel.com>; dev@dpdk.org; Burakov, Anatoly > <anatoly.bura...@intel.com> > Cc: maxime.coque...@redhat.com; Xia, Chenbo <chenbo....@intel.com>; Hu, > Jiayu <jiayu...@intel.com>; Richardson, Bruce <bruce.richard...@intel.com> > Subject: Re: [PATCH] doc: announce change in vfio dma mapping > > On 8/31/2021 2:10 PM, Xuan Ding wrote: > > Currently, the VFIO subsystem will compact adjacent DMA regions for the > > purposes of saving space in the internal list of mappings. This has a > > side effect of compacting two separate mappings that just happen to be > > adjacent in memory. Since VFIO implementation on IA platforms also does > > not allow partial unmapping of memory mapped for DMA, the current > DPDK > > VFIO implementation will prevent unmapping of accidentally adjacent > > maps even though it could have been unmapped [1]. > > > > The proper fix for this issue is to change the VFIO DMA mapping API to > > also include page size, and always map memory page-by-page. > > > > [1] https://mails.dpdk.org/archives/dev/2021-July/213493.html > > > > Signed-off-by: Xuan Ding <xuan.d...@intel.com> > > --- > > doc/guides/rel_notes/deprecation.rst | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > > index 76a4abfd6b..1234420caf 100644 > > --- a/doc/guides/rel_notes/deprecation.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > @@ -287,3 +287,6 @@ Deprecation Notices > > reserved bytes to 2 (from 3), and use 1 byte to indicate warnings and > other > > information from the crypto/security operation. This field will be used > > to > > communicate events such as soft expiry with IPsec in lookaside mode. > > + > > +* vfio: the functions `rte_vfio_container_dma_map` will be amended to > > + include page size. This change is targeted for DPDK 22.02. > > > > Is this means adding a new parameter to API? > If so this is an ABI/API break and we can't do this change in the 22.02.
Our original plan is add a new parameter in order not to use a new function name, so you mean, any changes to the API can only be done in the LTS version? If so, we can only add a new API and retire the old one in 22.11. Thanks for you classification.
