Re: [pmacct-discussion] effort to relicense pmacct from GPL to a BSD-style license

2020-01-08 Thread Vincent Bernat
❦ 8 janvier 2020 14:52 +01, Job Snijders : > REQUEST TO THE PMACCT CONTRIBUTOR COMMUNITY > --- > > If you have contributed to the pmacct project (your name may be listed > below), please consider a reply-all to this email expressing your > explicit

Re: [pmacct-discussion] [RFC] Patches to allow capturing specific PF_PACKET protocols

2017-08-30 Thread Vincent Bernat
❦ 30 août 2017 13:58 GMT, Paolo Lucente  : > Fantastic, please proceed. I guess the patch should be wrapped around > some version checking of libpcap a-la if greater or equal than current > release in master then compile the code. I did jus review configure.ac > and libpcap

Re: [pmacct-discussion] building version 1.6.1

2016-11-09 Thread Vincent Bernat
❦ 9 novembre 2016 11:56 -0500, Stephen Clark  : LIBS . : -L/usr/pgsql-9.4/lib -ldl -L/usr/local/lib -lpfring -lpcap -lrt -lnuma -lz -lpthread >>> If libpfring is linked to one version of libpcap and your local libpcap >>> is another one, there will a

Re: [pmacct-discussion] Problem compiling on Debian Jessie

2016-07-06 Thread Vincent Bernat
❦ 6 juillet 2016 09:04 CEST, Johan Sjöberg  : > Yes, don't know why it complained about MySQL client > libraries. Configure also completed successfully without > --enable-mysql. So it was somehow related to MySQL. It's just that MySQL was the next test. Your

Re: [pmacct-discussion] Problem compiling on Debian Jessie

2016-07-05 Thread Vincent Bernat
❦ 5 juillet 2016 14:58 CEST, Johan Sjöberg  : > We have been running pmacct 1.2.5 on Debian Squeeze for many years. We > are now trying to set up a new server, running Debian Jessie. I have > downloaded pmacct 1.6.0 (and also 1.5.3), and tried compiling it. > > On

Re: [pmacct-discussion] pcap/ulog performance on Linux

2016-03-01 Thread Vincent Bernat
❦ 29 février 2016 19:30 +0100, Vincent Bernat <ber...@luffy.cx> : >> You are right with your assumption. Support of NFLOG has been requested, >> ie. to support IPv6, but is still pending and i don't have it currently >> on my radar (ie. 1.6.0 / 1.6.1). > >

Re: [pmacct-discussion] pcap/ulog performance on Linux

2016-02-29 Thread Vincent Bernat
❦ 29 février 2016 18:12 GMT, Paolo Lucente  : > You are right with your assumption. Support of NFLOG has been requested, > ie. to support IPv6, but is still pending and i don't have it currently > on my radar (ie. 1.6.0 / 1.6.1). Can I add it through the use of

Re: [pmacct-discussion] pcap/ulog performance on Linux

2016-02-29 Thread Vincent Bernat
❦ 26 février 2016 17:53 +0100, Vincent Bernat <ber...@luffy.cx> : > Has someone already done some simple benchmarks to check the performance > of libpcap-based capture with libpcap >= 1.0.0 (mmap support) and Linux > kernel >= 2.6.27 (64bit support). There is another milesto

[pmacct-discussion] pcap/ulog performance on Linux

2016-02-26 Thread Vincent Bernat
Hey! Has someone already done some simple benchmarks to check the performance of libpcap-based capture with libpcap >= 1.0.0 (mmap support) and Linux kernel >= 2.6.27 (64bit support). There is another milestone which is libpcap >= 1.5 and Linux kernel >= 3.10 (support for TPACKET_V3)? How would

Re: [pmacct-discussion] pmacct-contribs now on GitHub

2013-05-12 Thread Vincent Bernat
expectation (first line should be a subject), so the list of commits is a bit odd. -- Vincent Bernat | vincent.ber...@dailymotion.com Dailymotion | 140 Boulevard Malesherbes | 75017 Paris | France ___ pmacct-discussion mailing list http://www.pmacct.net

[pmacct-discussion] (no subject)

2012-12-07 Thread Vincent Bernat
Hi! Here is a patch to use INSERT ... ON DUPLICATE KEY UPDATE instead of just UPDATE. This increases the performance by an order of magnitude with MySQL. This relies on the fact that the WHERE clause is equivalent to the primary key. There is no option for this because it supported by MySQL

[pmacct-discussion] [PATCH 1/2] mysql: use INSERT ... ON DUPLICATE KEY UPDATE ... instead of just UPDATE

2012-12-07 Thread Vincent Bernat
The regular INSERT is kept, mostly in case where the user has requested do not use UPDATE. This still allows pmacct to do bulk INSERT. However, the regular INSERT should not run in other cases, hence getting better performance. --- src/mysql_plugin.c | 25 + 1 file

[pmacct-discussion] [PATCH 2/2] Use PRIu64 and PRIu32 for when formatting u64 and u32.

2012-12-07 Thread Vincent Bernat
There is not guarantee that %llu is appropriate to print u_int64_t. See: http://stackoverflow.com/questions/2844/how-do-you-printf-an-unsigned-long-long-int --- src/mysql_plugin.c | 14 +++--- src/pgsql_plugin.c | 35 +++ src/pmacct-defines.h |