ed.sealing at sealingtech.org
Sun Apr 9 07:14:46 PDT 2017
On Sun, Apr 9, 2017 at 5:06 AM, Jan Grashöfer <jan.grashoefer at gmail.com>
> > Any idea if this will be supported? I can not find any reference in the
> > past year indicating this one way or another.
> >From what I've read so far (e.g.,
> https://www.napatech.com/dpdk-packet-capture-pdump/), I wouldn't expect
> major performance boosts. Therefore I am curios: Where so you see the
> benefits of using dpdk?
I believe there would be some benefits in the ability to run high-speed
packet capture in VMs or Containers that are hosted on a cloud management
system (CMS). The world of NFV and service function chaining (which
encompasses IDSs such as Bro) often relies on DPDK applications.
Many of the CMS providers (e.g. Openstack, Kubernetes, etc) rely on
DPDK-enabled vSwitches such as OVS and VPP for accelerated packet
distribution. A DPDK-enabled Bro would be able to take advantage of
bypassing the VM kernel as well as reading the packets directly from the
vSwitches shared memory (some possible security concerns there).
A brief overview of how this would work with openvswitch is at .
Other potential benefits areas for the virtual space are when using SR-IOV,
which have different drivers (ixgbevf & i40evf) that aren't widely
supported by zero-copy technologies (NOTE: netmap has recently included
support for ixgbevf, and packet-bricks may be able to read from virtio
devices and fanout, but I haven't tested yet).
I don't know that these benefits are enough to justify the amount of
development work it would take to implement and maintain a DPDK packet
acquisition plugin. Just throwing out an answer to the question. :-)
> Bro mailing list
> bro at bro-ids.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bro