Hi Alfredo, No reason not to cache it inside the application, but why let any application to implement it, if its possible to implement it in pf_ring's userspace API (the way I mentioned)? BTW, if its sounds reasonable, I can push a suggested solution, and you can consider adopting it.
Amir On Thu, May 3, 2018 at 4:11 PM, Alfredo Cardigliano <[email protected]> wrote: > Hi Amir > ring_id should not change, thus it can be cached in userspace, > any reason you cannot cache it inside the application? > > Alfredo > > > On 3 May 2018, at 15:09, Amir Kaduri <[email protected]> wrote: > > > > User-space API function pfring_get_ring_id() always bring the ring id > from the kernel. In some applications, this API call might be used within > debug messages, in order to be able to track a relevant ring. If the > application uses this API too often (for debugging purposes), there could > be too much calls for the kernel, for getting information that usually > doesn't change. > > So my questions are: > > 1. Once a ring is initialized with a ring_id (in function > ring_create()), will it ever be changed during the application life-time? > > 2. Assuming the answer is negative (i.e. once a ring id is determined, > it doesn't change), > > is there a room for caching this value in userspace and avoid future > calls to kernel? > > (e.g. by adding "ring_id" member to "struct __pfring" in pfring.h, and > let function pfring_mod_get_ring_id() to return it once initialized, > instead of the call to getsockopt(.. SO_GET_RING_ID ..)) > > > > Thanks, Amir > > > > > > _______________________________________________ > > Ntop-misc mailing list > > [email protected] > > http://listgateway.unipi.it/mailman/listinfo/ntop-misc > > > _______________________________________________ > Ntop-misc mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop-misc >
_______________________________________________ Ntop-misc mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-misc
