From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 06AF2A04F1; Mon, 9 Dec 2019 14:41:38 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5626C2BAB; Mon, 9 Dec 2019 14:41:38 +0100 (CET) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 0EA1C23D for ; Mon, 9 Dec 2019 14:41:35 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Dec 2019 05:41:34 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,294,1571727600"; d="scan'208";a="237752912" Received: from orsmsx102.amr.corp.intel.com ([10.22.225.129]) by fmsmga004.fm.intel.com with ESMTP; 09 Dec 2019 05:41:34 -0800 Received: from orsmsx116.amr.corp.intel.com (10.22.240.14) by ORSMSX102.amr.corp.intel.com (10.22.225.129) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 9 Dec 2019 05:41:34 -0800 Received: from ORSEDG001.ED.cps.intel.com (10.7.248.4) by ORSMSX116.amr.corp.intel.com (10.22.240.14) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 9 Dec 2019 05:41:34 -0800 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (104.47.36.53) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 9 Dec 2019 05:41:33 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TAnchHjRnyAOH11Mszm7eEvWCwWHN2BiJ6L7M6Qj5s3ITku6waMbvUVaOxOD/NQg2ZQWHhb2T006w9KEQOs0pVxjJcMWchK6QiWKFoFKVP625Qux607facDtSuYH/KmMLVEnjKtrc9VVxfU5phJMXou3/47gAmolHkb+FqxEk1Lju+PMQg+Eizd+udf4Ob88xktnQrd6mf/1KjuORFOFlGDXTzDigNkHh3rCgte9gs3FOG80NDrGVl0nhUWcibwaygaHtH0bUMY8Bn+S/BqsFftXlkpWmTgxDGJtbJ/4hpXkoKVdYgS1j55rH43wXY3kETaj8feJjug7J/2tKpWpCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Faq2RGYwO8fsVIwCVRsFbaVKYDL7qinhY88UnN1gYC8=; b=ZpH+Bq55pVT68OWXFW4W4F0DK2yR0KJAX8/Sc5HQ0CvHMmOWioHhYGFXnyIprjm+9oMEbKZhA8WL3ZVg3nRptYZm5Y5vD8+0bPiNYxSaY6KFCf3N/pONdFp0r5WT4DMMRolG8AFh1eN099BfK+pXxSnQ0xCxSZoNiYjvTsd/q4taV4kmf7UDFXFwUyDgPgw81t3Ik7pu8c2k4ISQgDvcUOQr/9+IXGrIRyjBms8/RWBdhgRHrUg7K3l/oRAZ8YetCH3tMQGVtKYl+K0518kUNUIObHUKu3qK6wW/z2C9P/RscFblkKrdSagDGPkqlzdpQBbmjva6aPYTnM4R5lvh/g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Faq2RGYwO8fsVIwCVRsFbaVKYDL7qinhY88UnN1gYC8=; b=uxJsjnMYJzO8EF30jYrABIKlHSWpxszYkzC2y1kISTdjmgBTD5k0rmrHyBN/y45LJH1mAikOeCmij3R45UmKM3o1H0acXAn5uAhl/eS6O0VPT/fZ1N1McZi46182ew07g/TxsLvoLtBwJ2R9k1+TfYQpNP0BWL22OuRVpDeHxCU= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2532.namprd11.prod.outlook.com (52.135.244.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.14; Mon, 9 Dec 2019 13:41:31 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5c82:bb6a:d0f0:b802]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5c82:bb6a:d0f0:b802%6]) with mapi id 15.20.2516.018; Mon, 9 Dec 2019 13:41:31 +0000 From: "Ananyev, Konstantin" To: Stephen Hemminger , Ray Kinsella CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] RFC - adding filter to packet capture API Thread-Index: AQHVrII722vmbyTcMkyXVFsTzEY4kKexzoQA Date: Mon, 9 Dec 2019 13:41:30 +0000 Message-ID: References: <20191206141114.6b7d6d60@hermes.lan> In-Reply-To: <20191206141114.6b7d6d60@hermes.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiM2E4M2M4ZWQtZTEyOS00ODY1LWEwYTYtOGE3OGY3ZGY1Nzk3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiMGZJMXMwcWhGY1NUSStlb0c5OFNDb0lnM1NqUXNrQmtJNFUzeVJVNDB6aURXZk9cL2N0b2M0ZzJBbDBJUndyWmsifQ== dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.2.0.6 x-ctpclassification: CTP_NT authentication-results: spf=none (sender IP is ) smtp.mailfrom=konstantin.ananyev@intel.com; x-originating-ip: [192.198.151.184] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e01621f1-aced-4149-8d7a-08d77cad7fcb x-ms-traffictypediagnostic: BN7PR11MB2532: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 02462830BE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(366004)(346002)(396003)(376002)(189003)(199004)(229853002)(55016002)(81156014)(110136005)(8676002)(316002)(8936002)(5660300002)(52536014)(81166006)(26005)(4326008)(2906002)(186003)(478600001)(9686003)(64756008)(6506007)(66946007)(66556008)(66476007)(66446008)(76116006)(7696005)(305945005)(86362001)(71190400001)(33656002)(71200400001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR11MB2532; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: MeHRd6jjYPrGP573dtbFvvmcoBtlEpcQ1g+a8x0bdVusez901lTIsvM+p8vZDfC0/9bKmOd26yv8NAFecOqNr1npSxqcMZH70XGSEMWXqeb9R2HRPuT7CifVKkoIEfIbRgU39mX6Kz2MTUn3cTYEprllEbfJVG0TrDsBg/C6sw8tyDhUIX5I9XVK57G8vvmTV2190ItzsE1EAjv/Q1dSM12SFlfuGnu06aS7N7leYyHRwQtZCE+T/Dgu8xDji7VwjXEbgFHzrttya4+Gf0w+aqbGS2+FigV1pRMNi12sLEJs9GYZK4uMWWqILAJZh0nQGaoTjG3XcTXVa+SjKLhtAxYxos4aFycB6ss8geXYFEXOQAKKTypfrbEkcV6Nb3VfQZaDV3oHXwH2cd0Rcpq3IUheEscyEJt1nfAkuPMCHds3moAWT/U9qdx0Nk7TAQIm x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e01621f1-aced-4149-8d7a-08d77cad7fcb X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2019 13:41:30.8409 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 53GREHBkKybqysMjvLXoIh8u2Oay1u5dsGXGrmwc34FXc2RYHOwkwiKH//LnPaisUNndI0BjJwxgVtX82LItw0JFiVXeAgbssPsVr5Sg0Z8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2532 X-OriginatorOrg: intel.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > In the process of updating packet capture to take a filter program, there > is one open question about API/ABI. >=20 > The example is: >=20 > int > rte_pdump_enable(uint16_t port, uint16_t queue, uint32_t flags, > struct rte_ring *ring, > struct rte_mempool *mp, > void *filter); >=20 > For the new version want to add ability to pass a BPF (classic) program > from libcap. This is described in most pcap API's as "struct bpf_program"= . >=20 > The filter parameter was left as a placeholder, but in typical YAGNI > fashion. When we do need to use it, it is not going to work out. >=20 > Since the existing filter argument was never used, there are a bunch > of options (in order from best to worse). >=20 > 1. Introduce new API which takes a filter. >=20 > int > rte_pdump_enable_bpf(uint16_t port, uint16_t queue, uint32_t flags, > struct rte_ring *ring, > struct rte_mempool *mp, > const struct bpf_program *filter); >=20 > The old API is just the same as calling new API with NULL as filter. > This solution is safe but adds minor bloat. >=20 > 2. Use API versioning. This solves the ABI problem but it is still > an API breakage since program that was passing junk would still > not compile. >=20 > 3. Change the function signature of existing API. This risks breaking > at compile time some program that was passing some other value. > Similarly, a program could have passed garbage, we never checked. >=20 > 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. >=20 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 =3D 1, /* receive direction */ RTE_PDUMP_FLAG_TX =3D 2, /* transmit direction */ + RTE_PDUMP_FLAG_CBPF =3D 4, /* filter points to struct bpf_program */ /* both receive and transmit directions */ RTE_PDUMP_FLAG_RXTX =3D (RTE_PDUMP_FLAG_RX|RTE_PDUMP_FLAG_TX) };