From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by inbox.dpdk.org (Postfix) with ESMTP id A8535A04F1;
	Mon,  9 Dec 2019 17:49:31 +0100 (CET)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id 0D30C1B9B5;
	Mon,  9 Dec 2019 17:49:31 +0100 (CET)
Received: from mail-pl1-f196.google.com (mail-pl1-f196.google.com
 [209.85.214.196]) by dpdk.org (Postfix) with ESMTP id 160971B13C
 for <dev@dpdk.org>; Mon,  9 Dec 2019 17:49:28 +0100 (CET)
Received: by mail-pl1-f196.google.com with SMTP id x13so6030505plr.9
 for <dev@dpdk.org>; Mon, 09 Dec 2019 08:49:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=networkplumber-org.20150623.gappssmtp.com; s=20150623;
 h=date:from:to:cc:subject:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=vUhhW7xgOCZRw9nq6JQOtOkkTBeoxFEpONjJbXFewmc=;
 b=IzwCAL7VJ1NeAnHGQoZM21ChLiRl0Drpu07u3CdFHXOrSA6cfqkr22ek+I86UqkTnl
 wNPG0BmBNilIAAKlch3vDdekTzliDtHze5zeVVIRkA8YeQdpIf6tjOQD0HyG60E99X1d
 6+c1h+eaeC972dxiMXss1o9b8564fBNC6idztmNrdtVnuzM0LIGYJAKvhzyRe6iIW4wT
 pXbGYcvcQU8y7/EQ/RDbweS1vlHh7YOt1ZkO1dUB8I2NgbqIHZSC64l1Y+BmPx+UCz/4
 jXaONbVG8n3xomL6vsLFXUGksUtIqT2feL5QLtSkXFd/VXILSzEECbgoIXZcDjZ+e/rD
 JMQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=vUhhW7xgOCZRw9nq6JQOtOkkTBeoxFEpONjJbXFewmc=;
 b=VXv9eEXJ4kY2PjOZrf0t8MRC/ZaBslHJi31na0/Zcvec5RcUc8ONUR9WySP6igI3DB
 U1rHyj2XJ5mNnjgEozP2udVvA/aTU+kg1Eunmg11hcA97+ocGHl898I/5oVu2+gChlop
 caJD10ZhACaFuYjj5cBOPlEQI7ILV3boPPCHRW5ikzSb+hrOEoqnVkGNiznGgjdga/70
 /KI3svrHtwwLJdouDSWLfUIgGLExgMNkr4UeC8pvohYGZlbBn7FBaHUUN8QCiS75XBfr
 wEBwH/Tk53RzZ4F7CwtizBfvjPsGkaWaXv09LhysZSDI+SOjrvp+SFDy89tJDdvvt6yP
 qqtQ==
X-Gm-Message-State: APjAAAUWGUE1wNGgjCTasSObPghswmLq4Dyw0UQFGPD8d55GL4xHsBgy
 vEj8ZInHTtHukTmOPclRD3dcGg==
X-Google-Smtp-Source: APXvYqwdgo1o55UOoaJQOJGaHH2EuiqPZXzFobfwPgyb8f6NxbW4tLGhRPFdcdnk1SW4uabuZ4HHXw==
X-Received: by 2002:a17:902:b690:: with SMTP id
 c16mr6609162pls.72.1575910167965; 
 Mon, 09 Dec 2019 08:49:27 -0800 (PST)
Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127])
 by smtp.gmail.com with ESMTPSA id d24sm482pfq.75.2019.12.09.08.49.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 09 Dec 2019 08:49:27 -0800 (PST)
Date: Mon, 9 Dec 2019 08:49:18 -0800
From: Stephen Hemminger <stephen@networkplumber.org>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Cc: Ray Kinsella <mdr@ashroe.eu>, "dev@dpdk.org" <dev@dpdk.org>
Message-ID: <20191209084918.2bb2e3ec@hermes.lan>
In-Reply-To: <BN7PR11MB25474284881E2709966BCF8E9A580@BN7PR11MB2547.namprd11.prod.outlook.com>
References: <20191206141114.6b7d6d60@hermes.lan>
 <BN7PR11MB25474284881E2709966BCF8E9A580@BN7PR11MB2547.namprd11.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] RFC - adding filter to packet capture API
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Mon, 9 Dec 2019 13:41:30 +0000
"Ananyev, Konstantin" <konstantin.ananyev@intel.com> wrote:

> > 
> > 4. Keep existing function signature, but be type unsafe.
> >    This keeps API, but still is ABI breakage for programs that passed
> >    garbage. Plus C is unsafe enough already.
> >   
> 
> My preference is probably #4, with some extra changes:
> make actual type for 'filter' be determined by flags,
> something like:
> 
> enum {
>         RTE_PDUMP_FLAG_RX = 1,  /* receive direction */
>         RTE_PDUMP_FLAG_TX = 2,  /* transmit direction */
> +      RTE_PDUMP_FLAG_CBPF = 4, /* filter points to struct bpf_program */
>         /* both receive and transmit directions */
>         RTE_PDUMP_FLAG_RXTX = (RTE_PDUMP_FLAG_RX|RTE_PDUMP_FLAG_TX)
> };

Interesting but that is more awkward usage.