From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) by dpdk.org (Postfix) with ESMTP id 83C14231C for ; Tue, 1 Dec 2015 15:45:57 +0100 (CET) Received: by obbww6 with SMTP id ww6so6455861obb.0 for ; Tue, 01 Dec 2015 06:45:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=D/yJNhYl1URlFwPAYsPTVrQlGaFGjFOiIQhY6IdXLwI=; b=KjW985YphG4QnkWbxaU05q+1wqBpxzj7ZaTEfXuBrhcXVE4qsIftke8lPjN3R9p7BI Smd05NeNT1XTt/Vdmm6YQp6kFa5DgzzxWp0W7+B/gLi5a1/aaraageUHYwS8NzzupeBN 7+2Nug9wQ8xP3ZAx7/zROoR9CfLvaw0Z30OlToaIr+Xoz8EiskofqL1ONnivuu0U8HIK 5NL9HK1+tP3TDexqeGtQQQGna7W3734SKJ2OYq8MxvrLd6PlPZhglea7ZGrDtmj63AIj 0PbgTmrKj9c3St8CZ6w5g4fLC9S8behM83RjrsTyX3uBbnzwqJrSrG+VkvAACjHA9/fV lMzw== MIME-Version: 1.0 X-Received: by 10.60.17.1 with SMTP id k1mr33183926oed.4.1448981156923; Tue, 01 Dec 2015 06:45:56 -0800 (PST) Received: by 10.76.0.105 with HTTP; Tue, 1 Dec 2015 06:45:56 -0800 (PST) In-Reply-To: <20151201134228.GA21396@mhcomputing.net> References: <20151130171655.70e4ce25@xeon-e3> <20151201100333.GA32252@bricha3-MOBL3> <20151201.202639.45956937.shin@lenovo> <20151201115816.GA29824@bricha3-MOBL3> <20151201134228.GA21396@mhcomputing.net> Date: Tue, 1 Dec 2015 09:45:56 -0500 Message-ID: From: Kyle Larose To: Matthew Hall Content-Type: text/plain; charset=UTF-8 Cc: dev@dpdk.org Subject: Re: [dpdk-dev] 2.3 Roadmap X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 14:45:57 -0000 On Tue, Dec 1, 2015 at 8:42 AM, Matthew Hall wrote: > I am planning to use this to do the captures so you don't incur the headache > or performance issues with rte_kni. > > I am curious how I might be able to link it up w/ the standard libpcap based > tools to get an end-to-end solution with minimal loss Earlier Stephen mentioned using the named pipe behaviour of tcpdump. Is there an opportunity to take what you have mentioned here and marry it to the named pipe output to get the perf you need? Personally I have written a tool which sends packets out of a ring pmd in my main application. The associated rings are polled by another application which dumps to the packets to a pcap file. This has fairly good performance, though my implementation is quite crude. My point here is that sending to a named pipe may not be a bad idea. I don't know how the perf would compare, but it can't be that bad, can it? :P Things might get tricky thought if we need multiple queues to handle the rate of traffic being captured. Not sure how tcpdump would like that. I've also considered using cuse to expose a cdev that tcpdump could read from, but I'm not sure that tcpdump has that ability yet. > > Matthew. Thanks, Kyle