[Oisf-devel] Linux af-packet::mmap enhancement

[chetan loke]

Hello,

I recently came across the suricata project. I haven't looked at the
suricata code in detail and know nothing about the architecture. So if
my email doesn't make sense then please ignore it.

Around a month ago, I posted a patch(version1 on linux netdev) to enhance
mmap->TPACKET_V2 style packet-capture on linux. The new proposed
version 'TPACKET_V3' allows a user to essentially
request an entire block of packets rather than grabbing
packet-by-packet. The first link below explains the rationale of the
logic. And the sample code demonstrates how to capture/flush an entire
block.

Note: The patch itself may/may-not get accepted. But I am planning on
maintaining the patchset on the git repository mentioned below.
Soon(next month or so) I will roll out a kernel-rpm(mostly based on
FC15) and post it on the git repository. Thereafter, the plan is to
keep posting newer kernel-rpms or patched kernel(after pulling from
kernel.org) sources.


1) kernel patch - based on net-next.

http://marc.info/?l=linux-netdev&m=130870868502003&w=3
http://marc.info/?l=linux-kernel&m=130870870702028&w=3
http://marc.info/?l=linux-netdev&m=130870873902061&w=3


2) Sample user space C code:
git://lolpcap.git.sourceforge.net/gitroot/lolpcap/lolpcap

3) Notice the use of priv_space in the block-header. Search for 'csum'
in the sample C code.
   One can allocate say 'x' bytes and use it as a hole. Different
threads can stash data before passing it along to other threads.
   The kernel does NOT clean up that private area on purpose. So if
user space wants, that data can remain sticky.
   But user-space can also memset the entire/partial block before
releasing it back to the kernel.

4) Counters are provided to find out if you need to:
  4.1)  allocate more blocks
  4.2)  increase the time-out.


Regards
Chetan Loke