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 <cardigliano@ntop.org>
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 <akaduri75@gmail.com> 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 <cardigliano@ntop.org>
> 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 <akaduri75@gmail.com> 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
>> > Ntop-misc@listgateway.unipi.it
>> > http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>>
>>
>> _______________________________________________
>> Ntop-misc mailing list
>> Ntop-misc@listgateway.unipi.it
>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>>
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc@listgateway.unipi.it
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
>
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc@listgateway.unipi.it
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
