Cool, thank you, Anatoly and Kozlyuk. I haven't found how Windows implements the rte_mem_virt2phy.
Using an opaque structure pointer as the first argument is a good idea. Thanks, Feng Li Dmitry Kozlyuk <dmitry.kozl...@gmail.com> 于2020年4月20日周一 下午9:07写道： > > > On 20-Apr-20 12:09 PM, Li Feng wrote: > > > Using pread to replace lseek + read. > > > And add new APIs to reduce open/close/lseek system call frequency when the > > > user needs to convert a large range of virtual address space. > > > - rte_mem_virt2iova_with_fd > > > - rte_mem_virt2phy_with_fd > > > > > > Currently it will be used by spdk in spdk_mem_register. > > > > > > Signed-off-by: Li Feng <fen...@smartx.com> > > > --- > > > > These API's are IMO already on the verge of what's acceptable because of > > the differences between PA, DPDK IOVA and external memory IOVA. I'm not > > sure building on top of them is a good idea. It's also quite platform > > specific - rte_mem_virt2phy could potentially work with Windows (and in > > fact there was an RFC for it), but would this API work with Windows, > > given that Windows doesn't have fd's? Should we perhaps replace fd's > > with an opaque structure pointer, so that each platform-specific > > implementation could dereference it the way it needs to, without > > exposing internal details of the platform? > > These new APIs are, in fact, Linux-specific. Doubtfully will Windows ever > benefit from it even with fd abstracted, though I can't say for FreeBSD. Given > the linked suggestion to move rte_vfio_container_dma_map/unmap to some > include/linux header, maybe these APIs could land there too? > > http://mails.dpdk.org/archives/dev/2020-April/164404.html > > -- > Dmitry Kozlyuk -- The SmartX email address is only for business purpose. Any sent message that is not related to the business is not authorized or permitted by SmartX. 本邮箱为北京志凌海纳科技有限公司（SmartX）工作邮箱. 如本邮箱发出的邮件与工作无关,该邮件未得到本公司任何的明示或默示的授权.
