Re: [dpdk-dev] 2.3 Roadmap

[Yoshinobu Inoue <inoue.yoshinobu@jp.fujitsu.com>]

Hello DPDK list,

I've been so far just roughly reading messages, as I've been working on my
company's product based on DPDK1.6 for some time and haven't yet much
catched up to newer releases,
but as I implemented packet capture for my product just in a way as commented
here, (using KNI),

> Our current thinking is to use kni to mirror packets into the kernel itself,
> so that all standard linux capture tools can then be used.
> 
> /Bruce

I felt like giving commets from my humble experiences,,,

 - In our case, KNI is always enabeld for each DPDK port,
   as it seemed handy that packet rx/tx stat and up/down status can be checked
   by ifconfig as well.
   Also, iface MIB become available as well via /sys/devices/pci.../net.

   As far as we checked it, it seemed that just creating KNI itself didn't much
   affect Dplane performance.
   (Just when we update statistics, there is a bit of overhead.)

 - I inserted rte_kni_tx_burst() call to
   packet RX path (after rte_eth_rx_burst) and TX path (after rte_eth_tx_burst,
   based on an assumption that just sent out pkt is not yet freed, it will be
   freed when the tx descriptor is overwritten by some time later tx packet.).

   The call to rte_kni_tx_burst() is enabled/disabled by some external capture
   enable/disable command.

   I copy the packet beforehand and pass the copied one to rte_kni_tx_burst().
   In TX path, we might not need to copy if we just increment the packet refcnt
   by 1, but haven't yet tried such hack much.

   The packets sent to rte_kni_tx_burst() can then be captured by normal libpcap
   tools like tcpdump on the correspondent KNI.

   The performance loss when the capture was enabled was roughly 20-30%.
   (Perhaps it might change based on many factors.)

   By the way, in this way, we can enable tx-only or rx-only capture.


 - Some considerations,

   -  Someone might not like capture on/off check everytime on normal fast path
      tx/rx route.
      I too, so created fastpath send routine and slowpath send routine,
      and switched the function pointer when the capture is enabled/disabled.
      But not sure if it was worth for the effort.

   - In this approach, everyone needs to create their own capture enable/disable
     command in their implementation, and it could be a bit bothering.

     I myself am not sure if it's possible, but if as in normal tcpdump,
     an invocation of tcpdump to a KNI interfce could be somehow notified to
     the correspondent DPDK port user application, and then the call to
     rte_kni_tx_burst() could be automatically enabled/disabled, that's cool.

   
Thanks,
Yoshinobu Inoue


From: Bruce Richardson <bruce.richardson@intel.com>
Subject: Re: [dpdk-dev] 2.3 Roadmap
Date: Tue, 1 Dec 2015 10:03:33 +0000

> On Mon, Nov 30, 2015 at 05:16:55PM -0800, Stephen Hemminger wrote:
>> On Mon, 30 Nov 2015 22:53:50 +0000
>> Kyle Larose <klarose@sandvine.com> wrote:
>> 
>> > Hi Tim,
>> > 
>> > On Mon, Nov 30, 2015 at 3:50 PM, O'Driscoll, Tim <tim.odriscoll@intel.com> wrote:
>> > 
>> > > Tcpdump Support: Support for tcpdump will be added to DPDK. This will improve usability and debugging of DPDK applications.
>> > 
>> > I'm curious about the proposed tcpdump support. Is there a concrete plan for this, or is that still being looked into? Sandvine is interested in contributing to this effort. Anything we can do to help?
>> > 
>> > Thanks,
>> > 
>> > Kyle 
>> 
>> We discussed an Ovscon doing a simple example of how to have a thread use named pipe
>> support (already in tcpdump and wireshark). More complex solutions require changes to
>> libpcap and application interaction.
> 
> Our current thinking is to use kni to mirror packets into the kernel itself,
> so that all standard linux capture tools can then be used.
> 
> /Bruce
>