[Oisf-users] af_packet and rss queue count

[Cooper F. Nelson]

I can confirm this behavior as well.  We are successfully extracting
files off the wire and confirming their integrity via cryptographic hash.

I'm also using hardware offloading for reassembly via GRO.  This
reassembles TCP and UDP flows in kernel space and passes packets in
unified blocks of up to 64kb to user space.  So it's possible the packet
reordering issue is only a problem if you disable the hardware
offloading (which is on by default in all distros that I know of.)

I'll note that using hardware offloading for checksum and stream
reassembly results in some pretty significant performance improvements
for suricata, particularly with hyperscan.  The hs matcher in seems to
benefit from working with bigger blocks of packet data (I suspect due to
streaming issues with the suricata implementation).

I'm seeing about 10X (wow!) performance improvements over suricata 3.0
and 5X over 3.l without hardware offloading.

-Coop

On 1/26/2017 7:05 AM, erik clark wrote:
> If you set a symmetric queue (posted elsewhere in some thread), I believe
> you do not see issues with reordering. We have seen output from pf_ring and
> af_packet as being near identical in logged connections, events, so unless
> pf_ring is also mangling connectings the same way as if_packet/AF_PACKET,
> we can assume this is a non-issue. Packet loss is actually substantually
> lower for both suricata and bro using a symmetric key, proper udp/tcp
> hashing, and af_packet compared to pf_ring on identical hardware. It comes
> at cost of cpu over memory however.


-- 
Cooper Nelson
Network Security Analyst
UCSD ITS Security Team
cnelson at ucsd.edu x41042

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20170126/529d7bf4/attachment-0002.sig>