Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: NTop: Misc

Question about the PF_ring Paper

 

 

NTop misc RSS feed   Index | Next | Previous | View Threaded


neyshule at gmail

Jan 18, 2012, 7:17 PM

Post #1 of 3 (411 views)
Permalink
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


deri at ntop

Jan 21, 2012, 12:33 AM

Post #2 of 3 (379 views)
Permalink
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 [at] listgateway
> 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 [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop-misc


neyshule at gmail

Jan 21, 2012, 10:13 AM

Post #3 of 3 (378 views)
Permalink
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 [at] ntop>

> 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 [at] listgateway
> > 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 [at] listgateway
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>

NTop misc RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.