11/07/2020 05:27, Ma, LihongX:
> Tested-by:ma,lhong<lihongx...@intel.com>

For info, your name is written Lihong Ma <lihongx...@intel.com>

Please remove patch content and avoid top-post when sending a test tag.


> -----Original Message-----
> From: dev <dev-boun...@dpdk.org> On Behalf Of Thomas Monjalon
> Sent: Saturday, July 11, 2020 4:41 AM
> To: dev@dpdk.org
> Cc: david.march...@redhat.com; Yigit, Ferruh <ferruh.yi...@intel.com>; 
> gr...@u256.net; Zhang, AlvinX <alvinx.zh...@intel.com>; Xing, Beilei 
> <beilei.x...@intel.com>; Guo, Jia <jia....@intel.com>; Burakov, Anatoly 
> <anatoly.bura...@intel.com>; Richardson, Bruce <bruce.richard...@intel.com>; 
> dmitry.kozl...@gmail.com; navas...@linux.microsoft.com; 
> dmit...@microsoft.com; Kadam, Pallavi <pallavi.ka...@intel.com>; 
> tal...@mellanox.com
> Subject: [dpdk-dev] [PATCH v2] pci: keep API compatibility with mmap values
> 
> The function pci_map_resource() returns MAP_FAILED in case of error.
> When replacing the call to mmap() by rte_mem_map(), the error code became 
> NULL, breaking the API.
> This function is probably not used outside of DPDK, but it is still a problem 
> for two reasons:
>       - the deprecation process was not followed
>       - the Linux function pci_vfio_mmap_bar() is broken for i40e
> 
> The error code is reverted to the Unix value MAP_FAILED.
> Windows needs to define this special value (-1 as in Unix).
> After proper deprecation process, the API could be changed again if really 
> needed.
> 
> Because of the switch from mmap() to rte_mem_map(), another part of the API 
> was changed: "int additional_flags"
> are defined as "additional flags for the mapping range"
> without mentioning it was directly used in mmap().
> Currently it is directly used in rte_mem_map(), that's why the values 
> rte_map_flags must be mapped (sic) on the mmap ones in case of Unix OS.
> 
> These are side effects of a badly defined API using Unix values.
> 
> Bugzilla ID: 503
> Fixes: 2fd3567e5425 ("pci: use OS generic memory mapping functions")
> Cc: tal...@mellanox.com
> 
> Reported-by: David Marchand <david.march...@redhat.com>
> Signed-off-by: Thomas Monjalon <tho...@monjalon.net>




Reply via email to