Hi y'all.
I have a question about netmap - a novel framework for fast packet I/O.
OpenBSD packet I/O is already very fast from what i tested :)
On 7/13/12, Bahador NazariFard bahador.nazarif...@gmail.com wrote:
Hi y'all.
I have a question about netmap - a novel framework for fast packet I/O.
Does OpenBSD have any plan to support Netmap framework?
I also have a technical question about netmap and firewall relation.
As I read
framework for fast packet I/O.
Does OpenBSD have any plan to support Netmap framework?
I also have a technical question about netmap and firewall relation.
As I read and understand we can work with nic interface almost directly
form user land by netmap. what does mean that?
We have to pass
On Fri, Jul 13, 2012 at 11:59 AM, Chris Cappuccio ch...@nmedia.net wrote:
But having a generic mechanism to bring network data in/out userland for
analysis or manipulation, abstracted in a secure way from the kernel across
multiple network card types, and zero copy, could be very useful. The
Andres Perera [andre...@zoho.com] wrote:
On Fri, Jul 13, 2012 at 11:59 AM, Chris Cappuccio ch...@nmedia.net wrote:
But having a generic mechanism to bring network data in/out userland for
analysis or manipulation, abstracted in a secure way from the kernel across
multiple network card
from their site:
netmap implements a special device, /dev/netmap, which is the gateway
to switch one or more network cards to netmap mode, where the card's
datapath is disconnected from the operating system.
open(/dev/netmap) returns a file descriptor that can be used with
ioctl(fd, NIOCREG, ...)
Andres Perera [andre...@zoho.com] wrote:
so i should move the whole filtering stack to userland... seems like a
needless work for simple packet capture
And I completely disagree.
You think what the kernel does now is simple ?
On Fri, Jul 13, 2012 at 12:43:42PM -0700, Chris Cappuccio wrote:
Andres Perera [andre...@zoho.com] wrote:
On Fri, Jul 13, 2012 at 11:59 AM, Chris Cappuccio ch...@nmedia.net wrote:
But having a generic mechanism to bring network data in/out userland for
analysis or manipulation,
Andres Perera [andre...@zoho.com] wrote:
for clients (processes) that need to do trivial filtering, e.g.,
tcpdump 'ether multicast and not broadcast', it's an overhaul for
nothing
the placement of the filtering stack in the kernel is completely
irrelevant to how simple it will end up. if
Andres Perera [andre...@zoho.com] wrote:
i don't expect *every* application to manage the rx/tx rings directly,
reinject when they're done
Let's be more practical here. Luigi already gives you a stub pcap library that
does this for you. You can take an existing pcap application, link it to
for clients (processes) that need to do trivial filtering, e.g.,
tcpdump 'ether multicast and not broadcast', it's an overhaul for
nothing
the placement of the filtering stack in the kernel is completely
irrelevant to how simple it will end up. if you come up with a
sbin/bpfd it will still have
Claudio Jeker [cje...@diehard.n-r-g.com] wrote:
Why go through layers and layers of kernel processing for applications
that simply don't need to? That's the goal here. Not replacing BPF.
You think it is better to go through layers and layers of userland code?
In the end you need to do
On Fri, Jul 13, 2012 at 3:40 PM, Chris Cappuccio ch...@nmedia.net wrote:
Andres Perera [andre...@zoho.com] wrote:
for clients (processes) that need to do trivial filtering, e.g.,
tcpdump 'ether multicast and not broadcast', it's an overhaul for
nothing
the placement of the filtering stack in
On Fri, Jul 13, 2012 at 16:06, Andres Perera wrote:
you did! you explicitly said that it would be advantageous for
programs looking to perform analysis on captured packets. for those
programs, it turns out the placement of the filter doesn't matter
Sure it matters. Simple example: count
the comparison started against freebsd bpf's augmentations:
Zero-copy buffer mode
bpf devices may also operate in the BPF_BUFMODE_ZEROCOPY mode, in which
packet data is written directly into two user memory buffers by the ker-
nel, avoiding both system call and copying overhead.
On 07/13/2012 05:13 PM, Ted Unangst wrote:
On Fri, Jul 13, 2012 at 16:06, Andres Perera wrote:
you did! you explicitly said that it would be advantageous for
programs looking to perform analysis on captured packets. for those
programs, it turns out the placement of the filter doesn't matter
On Fri, Jul 13, 2012 at 17:56, Geoff Steckel wrote:
On 07/13/2012 05:13 PM, Ted Unangst wrote:
On Fri, Jul 13, 2012 at 16:06, Andres Perera wrote:
you did! you explicitly said that it would be advantageous for
programs looking to perform analysis on captured packets. for those
programs, it
On Fri, Jul 13, 2012 at 07:37:09PM -0400, Ted Unangst wrote:
On Fri, Jul 13, 2012 at 17:56, Geoff Steckel wrote:
On 07/13/2012 05:13 PM, Ted Unangst wrote:
On Fri, Jul 13, 2012 at 16:06, Andres Perera wrote:
you did! you explicitly said that it would be advantageous for
programs looking
Hi y'all.
I have a question about netmap - a novel framework for fast packet I/O.
Does OpenBSD have any plan to support Netmap framework?
I also have a technical question about netmap and firewall relation.
As I read and understand we can work with nic interface almost directly
form user land
19 matches
Mail list logo
