Mailing List Archive

Question about the PF_ring Paper
Hi Luca:
I have a small question about your paper "Beyond Device Polling":
*In the last month the real-time patch issue has been solved using an
adaptive poll*
*algorithm. In other words, whenever there are no packets to process, the
library sleeps*
*for a limited amount of time (usually a few nano-seconds, because
otherwise the system*
*will loose packets as the userspace application will not fetch packets
from the kernel)*
*before poll() is called. If, after the sleep, there are still no packets
available, poll() is*
*called, otherwise packets are processed immediately. The sleep time is
adapted*
*according to the incoming packet rate: the more incoming packets means
shorter (or*
*zero) sleep time. Thanks to this trick, poll() is called very seldom hence
avoiding the*
*need to improve system calls performance with third party patches.*

In this paragraph, you mentioned sleep, so where should sleep be put and
how to realize this nano scale sleep?
*
*
*
*
*
*
Best
Eugene
Re: Question about the PF_ring Paper [ In reply to ]
Eugene
this is old stuff. In the current PF_RING we use a different approach. We implement the concept of watermark (i.e. a minimum amount of packets that poll() will wait before waking up the app) so that when the app is awaken it has a few packets to process and thus avoids this constant poll/sleep/poll mechanism

Luca

On Jan 19, 2012, at 4:17 AM, shule ney wrote:

> Hi Luca:
> I have a small question about your paper "Beyond Device Polling":
> In the last month the real-time patch issue has been solved using an adaptive poll
> algorithm. In other words, whenever there are no packets to process, the library sleeps
> for a limited amount of time (usually a few nano-seconds, because otherwise the system
> will loose packets as the userspace application will not fetch packets from the kernel)
> before poll() is called. If, after the sleep, there are still no packets available, poll() is
> called, otherwise packets are processed immediately. The sleep time is adapted
> according to the incoming packet rate: the more incoming packets means shorter (or
> zero) sleep time. Thanks to this trick, poll() is called very seldom hence avoiding the
> need to improve system calls performance with third party patches.
>
> In this paragraph, you mentioned sleep, so where should sleep be put and how to realize this nano scale sleep?
>
>
>
> Best
> Eugene
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc@listgateway.unipi.it
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc

---

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan

_______________________________________________
Ntop-misc mailing list
Ntop-misc@listgateway.unipi.it
http://listgateway.unipi.it/mailman/listinfo/ntop-misc
Re: Question about the PF_ring Paper [ In reply to ]
*Much thanks for your reply, Luca:*
*The question is pfring_recv function is still the same. Watermark is just
added to different applications, like pfcount, I saw watermark here, but
the receiving mechanism is the same, isn't it?
*
2012/1/21 Luca Deri <deri@ntop.org>

> Eugene
> this is old stuff. In the current PF_RING we use a different approach. We
> implement the concept of watermark (i.e. a minimum amount of packets that
> poll() will wait before waking up the app) so that when the app is awaken
> it has a few packets to process and thus avoids this constant
> poll/sleep/poll mechanism
>
> Luca
>
> On Jan 19, 2012, at 4:17 AM, shule ney wrote:
>
> > Hi Luca:
> > I have a small question about your paper "Beyond Device Polling":
> > In the last month the real-time patch issue has been solved using an
> adaptive poll
> > algorithm. In other words, whenever there are no packets to process, the
> library sleeps
> > for a limited amount of time (usually a few nano-seconds, because
> otherwise the system
> > will loose packets as the userspace application will not fetch packets
> from the kernel)
> > before poll() is called. If, after the sleep, there are still no packets
> available, poll() is
> > called, otherwise packets are processed immediately. The sleep time is
> adapted
> > according to the incoming packet rate: the more incoming packets
> means shorter (or
> > zero) sleep time. Thanks to this trick, poll() is called very seldom
> hence avoiding the
> > need to improve system calls performance with third party patches.
> >
> > In this paragraph, you mentioned sleep, so where should sleep be put and
> how to realize this nano scale sleep?
> >
> >
> >
> > Best
> > Eugene
> > _______________________________________________
> > Ntop-misc mailing list
> > Ntop-misc@listgateway.unipi.it
> > http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
> ---
>
> "Debugging is twice as hard as writing the code in the first place.
> Therefore, if you write the code as cleverly as possible, you are, by
> definition, not smart enough to debug it. - Brian W. Kernighan
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc@listgateway.unipi.it
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>