lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMJ=MEd89zzLhxt7FYOVCbh5OzW+8jAsx38uV53zCodXvVtfMQ@mail.gmail.com>
Date:	Sat, 13 Oct 2012 10:39:27 +0200
From:	Ronny Meeus <ronny.meeus@...il.com>
To:	netdev <netdev@...r.kernel.org>
Subject: Question: How to configure the Ethernet receive buffer allocation
 (was: (no subject)).

Hello

I have an application that needs to handle a massive amount of
Ethernet packets coming from an FPGA on a dedicated Ethernet link.
I use a raw Ethernet socket for this. By increasing the receive buffer
of the socket, I'm able to capture all the packets and process them in
the application. Since this processing can take some time I have
increased the receive buffer to 500Mb. The size of the packets is
1000bytes so I'm able to capture 500k packets.

What I observe is that the kernel allocates buffers from the
slaballoctor for these packets but it takes buffers of 4k while in
fact the packet is only 1k (This means 2G of kernel memory  is being
used).
Is it possible to fine-tune this or is that an alternative for this?

I already investigated the PACKET_RX_RING solution. This has the
advantage that the buffers can be 1k but  I do not want to consume
500Mb of virtual memory in my application which is running on MIPS in
32 bit mode where I only have 2G available in user space.

---
Ronny
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ