From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 9EB188E7C for ; Mon, 14 Dec 2015 16:45:48 +0100 (CET) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id F2853C813; Mon, 14 Dec 2015 15:45:47 +0000 (UTC) Received: from aconole.bos.csb (dhcp-25-142.bos.redhat.com [10.18.25.142]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tBEFjlpc005210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 14 Dec 2015 10:45:47 -0500 From: Aaron Conole To: Morten =?utf-8?Q?Br=C3=B8rup?= References: <98CBD80474FA8B44BF855DF32C47DC358AF758@smartserver.smartshare.dk> Date: Mon, 14 Dec 2015 10:45:46 -0500 In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC358AF758@smartserver.smartshare.dk> ("Morten \=\?utf-8\?Q\?Br\=C3\=B8rup\=22's\?\= message of "Mon, 14 Dec 2015 10:57:10 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Cc: dev@dpdk.org Subject: Re: [dpdk-dev] tcpdump support in DPDK 2.3 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: Mon, 14 Dec 2015 15:45:48 -0000 Morten Br=C3=B8rup writes: > I noticed a discussion about support for tcpdump in DPDK 2.3. > >=20=20 > > Please consider which scenarios you want to support: Morten, Thanks for your input here. I think there's a different way of approaching this: "debuggability" (sorry, it's not grammatical). The end goal of having tcpdump is not just for another feature checklist that folks can just say "okay, welp we got that too!" When something is going wrong with communications, being able to fire up tcpdump without disturbing anything else is hugely important to isolating issues. I think that's an important scenario, and may be enabled by one or more of the features you've listed. There are other scenarios as well, that you hinted at - using existing applications built around libpcap. That is important to enable as well, but I think the biggest hurdle to getting anyone to use a DPDK enabled application will always be: "How much work do I have to do when something goes wrong?" There are certainly things that should belong in an application. But I think easy enabling of a tcpdump capable mechanism is DPDK's responsibility. After all, it's a networking stack, right? Whichever combination of features is used, we shouldn't really discourage them, I think. Any way the user can debug something using familiar workflows and tools is a way that dpdk-dev doesn't need to get involved. Just my $.02, anyway. Thanks, -Aaron