On Wed, Dec 14, 2016 at 11:33 PM, Vadim Kochan <vadi...@gmail.com> wrote:
> On Wed, Dec 14, 2016 at 11:26 PM, Tobias Klauser <tklau...@distanz.ch> wrote:
>> On 2016-12-12 at 22:09:52 +0100, Vadim Kochan <vadi...@gmail.com> wrote:
>>> Add new pcap io API to make pcap read/write accesses more
>>> simpler and generic. Added pcap_io & pcap_packet struct's to
>>> keep some internal pcap state like magic, link type & packet header
>>> instead of to pass them like parameters and keep it all within
>>> Also such approach might be used to unify sniffing from ring buffer via
>>> pcap io API similary as it is done with regular files.
>>> Some fast-path sensitive or setter/getter functions were inlined in
>> This series touches very sensitive fast-path code. Before even reviewing
>> it, I'd like to see performance measurments proofing that the your
>> patches don't introduce any performance regressions and that inlining of
>> these functions indeed does the job.
> Hm, yeah, I need to think how to perform this on my laptop ...
I will try to measure time execution of critical code via clock()
syscall for both versions if it will be OK for you, if yes -
would be it OK to add some #IFDEF's (ahhh not too nice probably) to
have such calculation persistent in the code ?
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.