Fabrizio
I don't know if it can help you. I have tested the cost of timestamping packets
in kernel on Linux and I can tell you that that is very little. If I remember
correctly suppose you are capturing 14.88 Mpps without timestamping packets,
adding timestamp with gettimeofday you will decrease
Dear all,
I have developed a new technology for Linux named TNAPI (Threaded NAPI)
that allows you to capture packets at wire speed at 1Gbit and multi-Gbit
at 10 Gbit (at least 3 million pps or more than 5 million pps with
packet filtering) by exploiting multiqueues and kernel threading. TNAPI
is ba
Guy,
no I haven't seen the message. I'll search on the mail archive and let
you know.
Thanks, Luca
Guy Harris wrote:
Luca Deri wrote:
is there any chance to see PF_RING support in libpcap source tree?
Please let me know if I can do something in order to push this process.
Hi all,
is there any chance to see PF_RING support in libpcap source tree?
Please let me know if I can do something in order to push this process.
Thanks, Luca
--
Luca Deri <[EMAIL PROTECTED]> http://luca.ntop.org/
skype://lucaderi/
Don't be en
pcap-linux.c code duplication into
pcap-pfring.* that I personally don't like.
Please let me know if the enclosed patch works on your environment.
Thanks in advance, Luca
On Jan 6, 2008, at 9:54 PM, Guy Harris wrote:
Luca Deri wrote:
your comments are very valuable: thanks. I have encl
means that PF_RING should be transparent to users beside
the speed advantage offered by PF_RING.
Other comments are inline.
pf_ring_patch.diff.gz
Description: GNU Zip compressed data
On Jan 6, 2008, at 11:17 AM, Guy Harris wrote:
Luca Deri wrote:
Yes it will work correctly as when the PF
On Jan 5, 2008, at 11:52 PM, Guy Harris wrote:
Luca Deri wrote:
On Dec 31, 2007, at 10:21 PM, Guy Harris wrote:
You might want to split the PF_RING support and the reentrancy
changes into two patches.
I have enclosed the patch for PF_RING.
I've checked in Paolo Abeni's patch
Paolo
===
RCS file: /tcpdump/master/libpcap/pcap-usb-linux.c,v
retrieving revision 1.20
diff -r1.20 pcap-usb-linux.c
652c652
< usb_read_linux_mmap(pcap_t *handle, int max_packets, pcap_handler
callback, u_char *user)
---
usb_rea
Guy
as I have explained in my previous reply, I don't think you're going
to use simultaneously pcap_loop and pcap_next_pkt, so I don't see a
problem here. However, this problem can be overcome by an if statement
like the one below
if(buf == handle->buffer) { <--- we use the s
Guy
pf_ring_patch.diff.gz
Description: GNU Zip compressed data
On Dec 31, 2007, at 10:21 PM, Guy Harris wrote:
Luca Deri wrote:
My patch also adds support for PF_RING (http://www.ntop.org/PF_RING.html
) that is a Linux packet acceleration technique that uses a shared
ring buffer
Gregor,
many thanks for your comments. Please see my comments inline.
On Dec 31, 2007, at 3:59 PM, Gregor Maier wrote:
Hi Luca,
Hi all,
I'm afraid, but I think your patch has a race condition under (at
least
under Linux). In Linux two syscalls are required to read a packet.
First
you read
11 matches
Mail list logo
