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

[Victor Julien]

On 06/22/2011 08:30 PM, chetan loke wrote:
> 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.

This certainly looks interesting to use in Suricata. We are currently
looking at adding AF_PACKET support, but we could use help. As you may
have seen on netdev David Miller is working on a cluster mode (FANOUT as
he calls it) for AF_PACKET, that looks very useful for us too.

> 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.

Makes sense as a performance improvement.

> 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

I see you got no replies to it. On list anyway.

> 
> 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.

Personally I won't have the cycles to look into this any time soon, but
would welcome help :)

Cheers,
Victor

-- 
---------------------------------------------
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
---------------------------------------------