Re: [dpdk-dev] 2.3 Roadmap

[Bruce Richardson <bruce.richardson@intel.com>]

On Tue, Dec 01, 2015 at 08:26:39PM +0900, Yoshinobu Inoue wrote:
> 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
> 
Hi,

that is indeed very similar to what we are thinking ourselves. Is there any of
what you have already done that you could contribute publically to save us
duplicating some of your effort? [The one big difference, is that we are not
thinking of enabling kni permanently for each port, as the ethtool support is
only present for a couple of NIC types, and solving that is a separate issue.:-)]

/Bruce