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 9AE45A04FA; Wed, 5 Feb 2020 22:16:09 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C47591C1A9; Wed, 5 Feb 2020 22:16:08 +0100 (CET) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 7DDE31C199 for ; Wed, 5 Feb 2020 22:16:06 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Feb 2020 13:16:04 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,407,1574150400"; d="scan'208";a="279488280" Received: from orsmsx103.amr.corp.intel.com ([10.22.225.130]) by FMSMGA003.fm.intel.com with ESMTP; 05 Feb 2020 13:16:04 -0800 Received: from ORSEDG001.ED.cps.intel.com (10.7.248.4) by ORSMSX103.amr.corp.intel.com (10.22.225.130) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 5 Feb 2020 13:16:03 -0800 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.172) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 5 Feb 2020 13:16:03 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JtmonYiUrGtW4pMIFdqE+7jHoHs3gTnX537H4O/J3EgCGDXrIXMCcvX35B8I8Wc9T8vkXzo1T0BQTzW9zGkoTHnQJmA0lVVqKgE1++aobwtpK8oclFXvN9kV3tomooNc0tFWrfgym6eLPwZdkW0nYbsVU6bEpjivLBLytrEDq0+vNrAKtd0lfD6KQ9UA58/oyqqlA1td22Bpag9mJANEwi+IFACoLOf3UVT3Ykh1cvopAWZBqbnkFq/IYKCByqhfRv0hiSMlX98vvMuHVd5vfzJ0FVm3w+3P3iKkH+pn2zN7dmyHfDd2pywix5NufwVi5V5QxvN3Sm3bdWeQZkRFqw== 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=m+wAXHrAYYhB2NaWy2EJyTQkgIMHuuncdOc1ZRTyRp0=; b=GWLtvhYTeLF1qB5ACv/dRr0U1bLjaD9c4ynvDk6joZ+Hef3zQA+iLK5y/zlWiYMayYzIyC2TwLeaMjRs/44Ys7t494/R7MI9mGEb0ylBBojXQaVa+oaVHnJnibJhUg9z1rv07iQu+PIZPS7KaPLdfpxG3scO7QUycVLIhrLpirHAm1ADvSUjsIz5fy8oPeiBGTkWC3LaneWLMKLMbzEsCbtmbvMuzc7uhR/WqNawWwKistZOAyEXCHqF6GnjUhc7Lgpf77gWW+OHZ688ki/xcDKcAQWq/pJByzdLlKMmmyX1elGyUJDfBisv2OyFSxMfJCcclpVPVjijBt09WyqLLg== 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=m+wAXHrAYYhB2NaWy2EJyTQkgIMHuuncdOc1ZRTyRp0=; b=AP41kpjFj58B4vYiX2tGKa8PSgPrK8PBB/U2d5IgZy3wbceD7tBo1+99ULBVbSI9Mgyqz0vVXrPIgGUXAx8YbRtsw6VrXfmrfQtd0a3WvVDOOnvcDK4xQkxuUiUdZAee/sBeGkh8eWWg08dD76Pi23gUirpgUaj1WFG6qGLLLcI= Received: from DM6PR11MB2556.namprd11.prod.outlook.com (20.176.99.10) by DM6PR11MB3259.namprd11.prod.outlook.com (20.176.121.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.29; Wed, 5 Feb 2020 21:16:01 +0000 Received: from DM6PR11MB2556.namprd11.prod.outlook.com ([fe80::513e:4aed:18d0:9b35]) by DM6PR11MB2556.namprd11.prod.outlook.com ([fe80::513e:4aed:18d0:9b35%7]) with mapi id 15.20.2686.031; Wed, 5 Feb 2020 21:16:01 +0000 From: "Ananyev, Konstantin" To: Stephen Hemminger CC: "dev@dpdk.org" , Jerin Jacob , "Varghese, Vipin" , "mb@smartsharesystems.com" Thread-Topic: BUG: eBPF missing BPF_ABS Thread-Index: AQHV22tb4aehtX82g0qpHcLazLeH5agM1y3Q Date: Wed, 5 Feb 2020 21:16:01 +0000 Message-ID: References: <20200204065229.0e8a85f7@shemminger-XPS-13-9360> In-Reply-To: <20200204065229.0e8a85f7@shemminger-XPS-13-9360> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZDQxMWRlNGYtNjA1Ni00ZGNhLTlmODktZTA2MDdlMzc0NDJkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiTm40VlgzREJJZmQ1c09nb1p3a3ZlUkI0cGFQY2lVbDA4NmRxbzlOU2dpeklTV0luaGJJZmlHU1dxTUlHZWRVYyJ9 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.160] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d2559c15-4c1f-4d1b-4803-08d7aa809a2b x-ms-traffictypediagnostic: DM6PR11MB3259: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0304E36CA3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(366004)(376002)(396003)(39860400002)(199004)(189003)(6506007)(33656002)(4326008)(2906002)(966005)(8676002)(66476007)(66556008)(54906003)(66946007)(66446008)(64756008)(52536014)(8936002)(5660300002)(86362001)(76116006)(7696005)(81166006)(81156014)(71200400001)(55016002)(6916009)(316002)(478600001)(26005)(9686003)(186003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR11MB3259; H:DM6PR11MB2556.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6EL+Cncj+zoLfKhYBqZc2xKoYk+iaUK2V0GTkaF83LiKPmwc2mKNmp1ZuKzzhkT9jWW8JOxh1ki8e01An8jrqItuxtkaIT+TvKZFl/yMMl44I/zsssM2oTvWxnbAtr+5lxtL4/3QDT5qGsT4LPiC0YbuSz/vYfHcf5ScP2iqiB0FXrL6M1yPjJeYp36WwNjxCeD7qc9p/oax7bYaOy6xp+YzNWZ6Cm5CwJZltrFfzsqhZ0kjHLpf0sIkb9DdDe63FrYZ90Sn8gjzALqsee2xJ1DbI9rZZX0CCtjg8CmQOlVa2LJXYr/GNLVsUwtkljUptzGs0Yftas60lY5IvIaItaEYiaXMzCJ3lKyVai2Hr80mAoraQ3cUe/RMfrxRX/ensIwaYcaemnEv7BOrZ284HRVPjf8m+nc7OJ6ywe1sqKIzKMZxqDkw5/lGrVi9dFxaoNVHycCorwL3LtuNYy2WXSAs+j3e9sEnZ47T0esSoYaF/OOmgjXGiWmsPzbAMr5pBKrQYHFlBjknLWXhw+n+xQ== x-ms-exchange-antispam-messagedata: 8U1HXC0kUEay8hw/xyJTMgbZZejtFZm/ezX0w1LsReT/1tBJEK1N/069VhVJRTyMhRxvepx/7uAD7m9kKa+EU59Ch7gwQAX0EZTDvl5rlJHlfDOI0zxFqDacKDMUrQeaeXL11UlcgvT0osWcESLJYA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d2559c15-4c1f-4d1b-4803-08d7aa809a2b X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2020 21:16:01.2539 (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: A2uUwqVvn4kA5Wp4WH8BfF/eiLNrBNy7mYwnPbNWZmzgx1bToNt14bugYTyzqU4Cch4+vfImB4GSS47fbgzF1/gWlyygBYzy2XBkgLeqH1U= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3259 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] BUG: eBPF missing BPF_ABS 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" >=20 > As I mentioned in my FOSDEM talk the current DPDK eBPF handling is > not usable for packet filters. I have ported the classic BPF to eBPF code > and the generated code is not usable by DPDK. >=20 > The problem is that DPDK eBPF does not implement all the opcodes. > BPF_ABS is not implemented and must be. It is in the Linux kernel. Yep, it doesn't. This is not a generic eBPF instruction, but sort of implicit function call to access skb data. At initial stage of librte_bpf development, I didn't think much about cBPF conversion, and to simplify things decided to put all special skb features aside. But sure, if that will enable DPDK cBPF support, let's add it in. Please fill a Bugzilla ticket to track that issue, and I'll try to find some time within 20.05 to look at it. Unless of course, you or someone else would like to volunteer for it. Though at first step, we probably need to decide what should be our requirements for it in terms of DPDK. >From https://www.kernel.org/doc/Documentation/networking/filter.txt: "eBPF has two non-generic instructions: (BPF_ABS | | BPF_LD) and (BPF_IND | | BPF_LD) which are used to access packet data. They had to be carried over from classic to have strong performance of socket filters running in eBPF interpreter. These instructions can only be used when interpreter context is a pointer to 'struct sk_buff' and have seven implicit operands. Register R6 is an implicit input that must contain pointer to sk_buff. Register R0 is an implicit output which contain= s the data fetched from the packet. Registers R1-R5 are scratch registers and must not be used to store the data across BPF_ABS | BPF_LD or BPF_IND | BPF_LD instructions. These instructions have implicit program exit condition as well. When eBPF program is trying to access the data beyond the packet boundary, the interpreter will abort the execution of the program. JIT compilers therefore must preserve this property. src_reg and imm32 fields are explicit inputs to these instructions. For example: BPF_IND | BPF_W | BPF_LD means: R0 =3D ntohl(*(u32 *) (((struct sk_buff *) R6)->data + src_reg + imm32)) and R1 - R5 were scratched." For RTE_BPF_ARG_PTR_MBUF context we probably want behavior similar to linux, i.e. BPF_IND | BPF_W | BPF_LD would mean something like: 1) uint32_t tmp; R0 =3D &tmp; R0 =3D rte_pktmbuf_read((const struct rte_mbuf *)R6, src_reg + imm32, sizeof(uint32_t), R0); if (R0 =3D=3D NULL) return FAILED;=20 R0 =3D ntohl(*(uint32_t *)R0);=20 =20 But what to do with when ctx is raw data buffer (RTE_BPF_ARG_PTR)? Should it be just: 2) R0 =3D ntohl(*(uint32_t *)(R6 + src_reg + imm32)); 3) not allow LD_ABS/LD_IND in this mode at all. Second question is implementation. I can see two main options here: a) if we plan to have our own cBPF->eBPF converter and support only it, we can add these extra instructions generation into converter itself. I.E. cBPF->eBPF conversion for LD_ABS/LD_IND will generate series of generic eBPF instructions. b) support eBPF LD_ABS/LD_IND in eBPF interpreter/jit =20 (a) probably a simpler way (eBPF interpreter/jit/verifier would remain unch= anged), but seems way too limited. So I think (b) is a better choice, even more wor= k implied=20 (interpreter seems more or less straightforward, jit would probably need so= me effort). Any thoughts/opinions? Konstantin >=20 > PCAP filter string: ip dst fosdem.org > cBPF program (6 insns): > L0: 28 00 00 00 0c 00 00 00 ldh [12] > L1: 15 00 00 03 00 08 00 00 jeq #0x800, L2, L5 > L2: 20 00 00 00 1e 00 00 00 ld [30] > L3: 15 00 00 01 8c 16 16 1f jeq #0x1f16168c, L4, L5 > L4: 06 00 00 00 ff ff ff ff ret #0xffffffff > L5: 06 00 00 00 00 00 00 00 ret #0x0 > eBPF program (11 insns): > L0: af 00 00 00 00 00 00 00 xor r0, r0 > L1: af 77 00 00 00 00 00 00 xor r7, r7 > L2: bf 16 00 00 00 00 00 00 mov r6, r1 > L3: 28 70 00 00 0c 00 00 00 ldh r0, [12] > L4: 55 00 04 00 00 08 00 00 jne r0, #0x800, L9 > L5: 20 70 00 00 1e 00 00 00 ldw r0, [30] > L6: 55 00 02 00 8c 16 16 1f jne r0, #0x1f16168c, L9 > L7: b4 00 00 00 01 00 00 00 mov32 r0, #0x1 > L8: 95 00 00 00 00 00 00 00 exit > L9: b4 00 00 00 02 00 00 00 mov32 r0, #0x2 > L10: 95 00 00 00 00 00 00 00 exit > validate: invalid opcode at pc: 3 > validate: invalid opcode at pc: 5 > rte_bpf_load failed: Invalid argument