From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com [209.85.218.47]) by dpdk.org (Postfix) with ESMTP id 1B78B5A86 for ; Thu, 17 Dec 2015 06:59:08 +0100 (CET) Received: by mail-oi0-f47.google.com with SMTP id y66so37456190oig.0 for ; Wed, 16 Dec 2015 21:59:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qwilt-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=K+ZPuHEt0JtfkUteOkpDJ08bVvIPUpg/NTxFN8EkiLA=; b=JRhY5FSPnXmpOaAROpB0J/ACWc/KKNJu/ZFgWcVt7hjYOm/gCoWKrqAIxW75bu8xw3 BeLXWkDVg3aNWEP9vvNjgyXR718or+U1BMaBmLOrcgZ2YDe1W206WcOQePJ6RKD319oi vZ62yQmtIzM0BLmFxLF2HL0Ak7z7+m0P3GhvYLGEhPCi/R0mC0vLwjd860jZUO3NBUyp hTkfL6QycRgjOSPd0Sh9/lZ8vwsLmkhDGr4ALgnzhcQywd40cTxIbW2A+a9IWgR5egv2 CKRZ7/Fr4se+R9KqBy3wYMhvheFTFNUeSYv/+J4Fr3WtSrAZk/vkFs1jsZgc5H5K4/Ey Ky0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=K+ZPuHEt0JtfkUteOkpDJ08bVvIPUpg/NTxFN8EkiLA=; b=PejN/gQvBG8d/bEEYCaQt7OEbVbYCcPhweZyuCXrAoiKjqrPhMVYESdUde+Jzh2c8/ LP5SyklslGRCKJtkMMlNFDWBI8aF5k/Xl6lel2ZFx6wVPmBi2u5KEWzCpZ5+V2EViCB+ UO4mmZJTrqT11uIarHHgrilp3OwAMBDMq2GgCb9uUKGSheWTnIfznTpw5MYBY3/GuAIX z99GW1uGhjG7SmCoGuab5An7yFkYc4N8ZgDCTNMUtZYZXegZIZEZYiDxzUoqlvndw+Ju QSAkj8iiz+kRnnSaXYAiAhtRCm6lQf/9DgZoHN8WwKVma7EdCK26wXUxtH6uj1C5qW+m tgbQ== X-Gm-Message-State: ALoCoQkR80BkVzAFngO8OC4PL7rIsCj7+2r7lEnpxW0Kuqg+iq7r/O9cv0dHJSOAdRoksPIXFCQLP0yyXRnV2ijQDSifnziGVg== MIME-Version: 1.0 X-Received: by 10.202.172.80 with SMTP id v77mr16381137oie.18.1450331947452; Wed, 16 Dec 2015 21:59:07 -0800 (PST) Received: by 10.202.65.139 with HTTP; Wed, 16 Dec 2015 21:59:07 -0800 (PST) In-Reply-To: <20151216233824.GA23052@mhcomputing.net> References: <20151214182931.GA17279@mhcomputing.net> <20151214223613.GC21163@mhcomputing.net> <20151216104502.GA10020@bricha3-MOBL3> <98CBD80474FA8B44BF855DF32C47DC358AF76F@smartserver.smartshare.dk> <20151216115611.GB10020@bricha3-MOBL3> <98CBD80474FA8B44BF855DF32C47DC358AF771@smartserver.smartshare.dk> <20151216131249.GC10020@bricha3-MOBL3> <98CBD80474FA8B44BF855DF32C47DC358AF776@smartserver.smartshare.dk> <20151216233824.GA23052@mhcomputing.net> Date: Thu, 17 Dec 2015 07:59:07 +0200 Message-ID: From: Arnon Warshavsky To: Matthew Hall Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: dev@dpdk.org, Morten B 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: Thu, 17 Dec 2015 05:59:08 -0000 Filtering and serializing are 2 different components. No need to bind them by default, and nothing prevents you from calling them both from the same context if that what works for your use case. On Thu, Dec 17, 2015 at 1:38 AM, Matthew Hall wrote= : > On Wed, Dec 16, 2015 at 11:45:46PM +0100, Morten Br=C3=B8rup wrote: > > Matthew presented a very important point a few hours ago: We don't need > > tcpdump support for debugging the application in a lab; we already have > > plenty of other tools for debugging what we are developing. We need > tcpdump > > support for debugging network issues in a production network. > > +1 > > > In my "hardened network appliance" world, a solution designed purely fo= r > > legacy applications (tcpdump, Wireshark etc.) is useless because the > network > > technician doesn't have access to these applications on the appliance. > > Maybe that's true on one exact system. But I've used a whole ton of syste= ms > including appliances where this was not true. I really do want to find a > way > to support them, but according to my recent discussions w/ Alex Nasonov w= ho > made bpfjit, I don't think it is possible without really tearing apart > libpcap. So for now the only good hope is Wireshark's Extcap support. > > > While a PC system running a DPDK based application might have plenty of > > spare lcores for filtering, the SmartShare appliances are already using > all > > lcores for dedicated purposes, so the runtime filtering has to be done = by > > the IO lcores (otherwise we would have to rehash everything and > reallocate > > some lcores for mirroring, which I strongly oppose). Our non-DPDK > firmware > > has also always been filtering directly in the fast path. > > The shared process stuff and weird leftover lcore stuff seems way too > complex > for me whether or not there are any spare lcores. To me it seems easier i= f > I > just call some function and hand it mbufs, and it would quickly check the= m > against a linked list of active filters if filters are present, or do > nothing > and return if no filter is active. > > > If the filter is so complex that it unexpectedly degrades the normal > traffic > > forwarding performance > > If bpfjit is used, I think it is very hard to affect the performance much= . > Unless you do something incredibly crazy. > > > Although it is generally considered bad design if a system's behavior (= or > > performance) changes unexpectedly when debugging features are being use= d, > > I think we can keep the behavior change quite small using something like > what > I described. > > > Other companies might prefer to keep their fast path performance > unaffected > > and dedicate/reallocate some lcores for filtering. > > It always starts out unaffected... then goes back to accepting a bit of > slowness when people are forced to re-learn how bad it is with no > debugging. I > have seen it again and again in many companies. Hence my proposal for > efficient lightweight debugging support from the beginning. > > > 1. BPF filtering (... a DPDK variant of bpfjit), > > +1 > > > 2. scalable packet queueing for the mirrored packets (probably multi > > producer, single or multi consumer) > > I hate queueing. Queueing always reduces max possible throughput because > queueing is inefficient. It is better just to put them where they need to > go > immediately (run to completion) while the mbufs are already prefetched. > > > Then the DPDK application can take care of interfacing to > > the attached application and outputting the mirrored packets to the > > appropriate destination > > Too complicated. Pcap and extcap should be working by default. > > > A note about packet ordering: Mirrored packets belonging to different > flows > > are probably out of order because of RSS, where multiple lcores > contribute > > to the mirror output. > > Where I worry is weird configurations where a flow can occur in >1 cores. > But > I think most users try not to do this. > --=20 *Arnon Warshavsky* *Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon@qwilt.com *