<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dmitry,<br>Thanks a lot for the reply. <br>1. The things look better now, but now we still have some capabilities left out in order for the program to run. I am myself not a kernel programmer and asked on <a href="https://stackoverflow.com/questions/73556145/understand-which-capability-exacty-lacks-to-complete-the-operation-in-linux">stackoverflow</a> the question on how can we deduce the exact capability that failed the check in kernel. Otherwise the process of finding the exact set can be very irritating. May be someone here will have the idea better than guessing for user space developers.</blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>-----<br>[user1@dredd examples]$ sudo setcap cap_ipc_lock,cap_sys_admin,cap_dac_override+ep ./dpdk-helloworld<br>[sudo] password for user1:<br>[user1@dredd examples]$ ./dpdk-helloworld<br>EAL: Detected CPU lcores: 4<br>EAL: Detected NUMA nodes: 1<br>EAL: Detected static linkage of DPDK<br>EAL: Multi-process socket /run/user/1000/dpdk/rte/mp_socket<br>EAL: Selected IOVA mode 'PA'<br>EAL: VFIO support initialized<br>EAL: Cannot open /dev/vfio/noiommu-0: Operation not permitted<br>EAL: Failed to open VFIO group 0<br>EAL: Requested device 0000:00:08.0 cannot be used<br>EAL: Cannot open /dev/vfio/noiommu-1: Operation not permitted<br>EAL: Failed to open VFIO group 1<br>EAL: Requested device 0000:00:09.0 cannot be used<br>TELEMETRY: No legacy callbacks, legacy socket not created<br>hello from core 1<br>hello from core 2<br>hello from core 3<br>hello from core 0<br><br>2. Thanks a lot for pointing out how it works. Regarding your second note, In my understanding, knowing physical addresses does not help any user process lacking the corresponding privileges. Because mapping and read permission are enforced by kernel & hardware, even knowing the physical memory address would not help regular process reading or updating it unless the physical page  was mapped by the kernel into process virtual space with proper permission.  <br><br>In addition it turns out that if one would like to debug DPDK or any other executable using a special capabilities set, this set must be duplicated in gdb (at least that's how it worked for me), otherwise it spawns debugee with reduced capabilities set ( I guess by means of bound set). If someone using VSCODE remote connection debug than also <br></blockquote><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>Thanks again for the help<br><br><br><br>
</blockquote></div></div>