Hi Alfredo, I didn't cache it since I didn't bare in mind that the implementation is like that. I discovered it by chance, when debugging something else. I can cache it of course quite easily and add a wrapping API in the application, but I asked myself why to do it in the application if the right thing is to do it in the original API. The use-case BTW, is when you want the application to periodically dump statistical information about the channels (rings). Its nice to have the ring_id dumped as well. Also, there is no API for reading the information of a socket (e.g. /proc/net/pf_ring/1234-eth0.567), so to create it, you need the ring_id, and here I thought that its better to get it directly from the API instead of a variable that I'll hold. Anyway, its not a big issue for me, I can cache it in my application of course. I just raised it as a point to think about.
Thanks, Amir On Thu, May 3, 2018 at 4:44 PM, Alfredo Cardigliano <[email protected]> wrote: > Hi Amir > please note I am not against caching it in the library, I was just > wondering > why you are not caching it in the application as it was the easiest > solution > and I am not aware of other use cases / applications reading it so often. > > Alfredo > > On 3 May 2018, at 15:40, Amir Kaduri <[email protected]> wrote: > > 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 > > > > _______________________________________________ > 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
