From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0057.outbound.protection.outlook.com [104.47.42.57]) by dpdk.org (Postfix) with ESMTP id C01CC1B6D8 for ; Mon, 9 Apr 2018 06:39:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fpnRHjOi9RFLVDWd8pid9lEhONRhYoIIB/qcUCmh4y8=; b=V5U4OlU2j4OV4RvMLYnt2CCkdeEZNK3Cpprf4BeJpKK0BxpXlLiobN1nMqFGebu1/EImj92HVOVfl/BT4ZeVpbClWDuy5VcXEF8WBLLRqhHH2MhSuYGmoMM6ClTeYw63t/UK8ZoyN76c7FXydNbQFywwsxBlWW10A2xio4ClQrk= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.JacobKollanukkaran@cavium.com; Received: from jerin (111.93.218.67) by CY1PR07MB2524.namprd07.prod.outlook.com (2a01:111:e400:c636::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Mon, 9 Apr 2018 04:39:05 +0000 Date: Mon, 9 Apr 2018 10:08:47 +0530 From: Jerin Jacob To: "Ananyev, Konstantin" Cc: "dev@dpdk.org" Message-ID: <20180409043845.GA7349@jerin> References: <1520613725-9176-1-git-send-email-konstantin.ananyev@intel.com> <1522431163-25621-6-git-send-email-konstantin.ananyev@intel.com> <20180402224440.GB1501@jerin> <2601191342CEEE43887BDE71AB977258A0AB7FA5@irsmsx105.ger.corp.intel.com> <20180403170015.GA24166@jerin> <2601191342CEEE43887BDE71AB977258A0AB8A4E@irsmsx105.ger.corp.intel.com> <20180404175146.GA8576@jerin> <2601191342CEEE43887BDE71AB977258A0AB9849@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2601191342CEEE43887BDE71AB977258A0AB9849@irsmsx105.ger.corp.intel.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Originating-IP: [111.93.218.67] X-ClientProxiedBy: BMXPR01CA0012.INDPRD01.PROD.OUTLOOK.COM (2603:1096:b00:d::22) To CY1PR07MB2524.namprd07.prod.outlook.com (2a01:111:e400:c636::15) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 571f39c3-8b25-4cf4-61f6-08d59dd3d460 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:CY1PR07MB2524; X-Microsoft-Exchange-Diagnostics: 1; CY1PR07MB2524; 3:CXHF8d/JUBzs1vCxrqgKdsMo4fAxehuc3glSxdAd5swEiPvU2vq0jSjZcS1cEnMfRnwVeqNjqg+UkPNI5a6X2yzZQmcePWZVIL5vEC7qw5P/Ihe3sWVWfkrc5b128FLiKS0I6bYCOmy7NZeoCAilDNhapjwfii6JmcYnEgSRYq6iSZ8/ZUkIYhraWjUSsLlc5ECRghDzIlLxWIXLMg+CmAvytmU1HC9GpUhRzUpYUJgHkqXku1+r1/D0UkCyu3xJ; 25:9z2JzByosBmHK1P0Lwqi5/WUhIM/EZMYSbv3IqqO8TSnkVS0+A+w9ECTy3qxp6tMpyLlpFbg3ji5wAe9BSNVn2OBE61MTqLtl5u2aWWn+r4Jyi7EMCD3oASNlUqQCEB1HH+tRwF3qp5rYikuc7FI2497dCkV/+bV3XnL8/crUuB+NlI0D+feQeZs1FHtkE8LVnEDLsnukjx67C72DDvS7NM4PK5z1GG6vH3Im1J7AXmD/aganAfcQLC668oW2Sh9RXjamGOwRZBCMr3BMhf0vDw1B8Bm0K+svcTzYPna3gUrwjv0DR3uqHaMsF8FhzlvV6Ua+S3SCSg1xk47pyZPiQ==; 31:SVBe2iKCijyNJX/5z2rNnFLFdV6pPLWHrNEY6xmGmcv+Wswny1+r+cQlb/gLJDBgYA3a1H34kP0Dk+QawSdz8RlcZPPET/cBTjz61IyJzQuI7QauUCFVYZDzzPgBwKZOS9Nx2tVCGmHPRuBuISEaRS9Os/1Qz4kxEy3q74OCoK5/DPkucr8JAHmq0Gb7vcjaeWHoNLFjIbXu4IyqwrjyEwMTAElSL8Go12NElKyXSBo= X-MS-TrafficTypeDiagnostic: CY1PR07MB2524: X-Microsoft-Exchange-Diagnostics: 1; CY1PR07MB2524; 20:EcdvS09OHX5E0a3F3a3TUyXWWMJ6L/+/FFZMHXPeL7LUiUPhVmuVdhXhr5QVIDuRAFP5LopljUBLdDONUWd3EqVQeTBITAW0UZ0YeQy34ZU7WQZJu5bZ2DVy/P/SP4vwp0kn/tvzuY7XbK0W4pPhQI25hV0GFyLqAImha6MjCd6lxM8WFmPWrEy283klqjQWo423mr3kuVKAequpgOaCVvQZit+KUADfiqwFG/sqiaRpCNXYpBioL0oRBh38lJxXQrTlMudWftSPCyjOjJlbHxQezZn4GzXQdthCMHlgRYcWaFzaVeyFILmwz18G4f7j4rsKgT6/bRJEWkOWT77k8l/XTCnWT2YSUHceOBCZXqFJL2GSZD1yJZArCrdwR5DCnhiqtGQHM+8Wy5e4QVgsBjyLHGaECq7qengqCcdDXo+MZF2cB1zwnvH/EO0je8opUB2JbRjHBDZ8/41TaEgNhtgwCXrCxh09YpH0wKtDlkee54/BQP5QaDqyDhFpu/UeAmWd68NhdUvU47D1M8Bf5gO92jucCb8S8LyCBI6pZZ7G79UJTlUvQsTXEmEWROBAI4aJHOGTXfOEgzrTG0feQlDozW+86PAjmLjdU5yeoJc=; 4:sKQW+ZL5jc4so659jpRdPo+Nlcr8DZkY19ZKZ3eUiBam6PU/wXl4cTMrenWyYNIM5cJSQUcceV563R4vcW34ktL0lqRuYzbnPa53skxcBVv9cZmbs50qYk+YIyAXBLC6BWNPQh7+uJcmt1GQ8MqRG5S7HaWsOhLrNcloei/PhgrAMr+QaFhbhHwXMRMa7kOhTLrdZ6QY7n/WVDep+DpWKU+5XkksEV1cP5l4ox1pbU3RlEEnvuU8SpQd4TWZbgxeuqoSFoKWTulF+L1qjdY6GCrLVqREL9X65wXvTAk/RRR6YuBztfXwRfLdMTIayrU8 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(228905959029699); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(3002001)(10201501046)(3231221)(944501327)(52105095)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:CY1PR07MB2524; BCL:0; PCL:0; RULEID:; SRVR:CY1PR07MB2524; X-Forefront-PRVS: 0637FCE711 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(346002)(376002)(396003)(366004)(39850400004)(39380400002)(11905935001)(189003)(199004)(13464003)(26005)(55016002)(33656002)(53936002)(6496006)(6246003)(6306002)(4326008)(33716001)(186003)(16526019)(9686003)(66066001)(47776003)(52116002)(561944003)(53376002)(229853002)(33896004)(1076002)(6666003)(5009440100003)(8936002)(6916009)(3846002)(76176011)(81156014)(81166006)(476003)(93886005)(956004)(106356001)(486006)(58126008)(16586007)(316002)(386003)(59450400001)(2906002)(446003)(68736007)(11346002)(6116002)(23726003)(8676002)(72206003)(478600001)(25786009)(105586002)(966005)(42882007)(50466002)(5660300001)(7736002)(97736004)(305945005)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR07MB2524; H:jerin; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR07MB2524; 23:c54LwXF0UxMv8UB7C9Y6x4Fgyyud32HolIfxOuCB2?= =?us-ascii?Q?nvk20QetfhLUGcD7/gqWqaDJTChojQgi4fmnKzUQsMdRYYQZ64OyiB+V3zXb?= =?us-ascii?Q?FoLSik7ODc6fMWYs4BBzmqsuGmoaWumap4e/RxS5oFXc5NFiMV5oyBuX7VRB?= =?us-ascii?Q?SfOg3DTF4yYoEBPedH92bWeNirE2UEaJgr0e2Ga+g7UP3478yZDp9Yl87BJd?= =?us-ascii?Q?NtvSJEcPKyUWfPO2NNu5oqxERUQkwT7FfgDpJGbnUaUsCOiv/8MNPomQ+0WR?= =?us-ascii?Q?Y8it/MYR93kXdxiST0CunGVKZ+tpxVKYBISiPy+u7DVCtVjCUWDnuTUV4UqW?= =?us-ascii?Q?K7rwmjBxlB/3EsAirqH+jR5yfP10PK7YyPc5wDTSlFkyQyGkk/Rtq6mZO0++?= =?us-ascii?Q?BUt0/w0eryYgZg5nR2v4uDtjff0TbQ6et3JuWfhcBTDitTlwUwNAOL1sokwQ?= =?us-ascii?Q?bEshGw2xEO2aIgBNRWn6RY13GKV+MfpOrU1CZMc+U7tIc51q+AaELd0o9Hh6?= =?us-ascii?Q?jcvRhYLFnMiGopcpV7C6k27SmV41+UEX/SQsWdm7az8k1DRdvwkTLgApvwMc?= =?us-ascii?Q?roHV0ikoY3dJj8wcVHpsjPQecZY/7kPmjufbcGbBWckb7qo52NH8Ji1yLBPE?= =?us-ascii?Q?uHn5vm/hlAy4m1+6PgoIMUWB6y0Hw7mIwT4s41UtgOrVY2uyUxvlSfGabMvS?= =?us-ascii?Q?8NbESzJqMTwbyd+SqQj6xeHbo6iPqouIpTbYMYM15qhjS0TkS6UqHBouMGY3?= =?us-ascii?Q?vvQPzT6E1a/67ng/+oY8ONOiS0le9chH217M7K/juMTjDx+QG5gw+I9KhESi?= =?us-ascii?Q?DvdgTaEeK9jZBUmDl4BNWurQZyFuEV/HnwNJeleDZU5ZvMyD1puIQ9a7+6YZ?= =?us-ascii?Q?kCg5+llN1DPaegauUMDNhIyLtmfsoaY/HSVwlJvidId/+CDVKkl4VxD7S6Ip?= =?us-ascii?Q?Jtc4PQcEi+3O3fRqYs9SB2BFxmDLaODZPDPJWqyby7Y2APHWKuvbF3qIYXEW?= =?us-ascii?Q?6hzwyGCvc59nN5w6925bUDbs2SRmlo7r7Ur95CI06m2bDIyq/eGrzrWVeEnC?= =?us-ascii?Q?RJTcssnnG8d95tIXL3/3eUkGzKlPrrPkSEL97zTeE+R2ZgTv3VexmTIux6JN?= =?us-ascii?Q?N+Zmv6FHdiK6qhxNkluaVeuCfkq5SLTSB3pGi1tKNa/WQCe4EAI+ecGuHZ03?= =?us-ascii?Q?b8PaKlBCsAHFsaf7SvirgqYAXmNtAxO/NHoao3qwTmwzyYYWURw8osVx3Nnf?= =?us-ascii?Q?ObJkupA3xBtChzcas7n2MBD1v5DZFiY2eCvNUuE1qZI6LuamxA6O4gmdjQf6?= =?us-ascii?Q?C9A004iSRuBX0X3GUZpkJ6bQY+DrsxINji1Ixm5xzq4aW90f9SRP3vbU3PG8?= =?us-ascii?Q?1fUuUyu75ceOEjqBqx8PAlHig2sLuxWxUo0ui/aK7rbs1U5C0J/xNF/11loj?= =?us-ascii?Q?3rKbv9CYe4j9T/6IPj3VUlUEpJ/oKrfQWzBZ3rMbYmC19cggPjLn6tJQjzzN?= =?us-ascii?Q?3d+U3E59s4J5LtZDURw2PShTYrpmDqUNMo=3D?= X-Microsoft-Antispam-Message-Info: dKcDYp0tChWHupNSWUN3tw5XvZdbEgmQvMZtX/aFX5/CV5MHuGpy6YLn6KriAfi6zm6rfz6RViaYrz9UxSCDWoHJAXlcn4NlAWEB54VN9SdK56sE4TkRpXRHAChfC1LK1CgvQc9Sq7nwXFGeHtBVbmqqu+3h+VRpt08uY2A75A195bawUAXgA9KKe4cudIPE X-Microsoft-Exchange-Diagnostics: 1; CY1PR07MB2524; 6:nhW3+O1ePyL41OYHO7AUoT6qFJ0dCiznp3doDPC31iUXr9GubKWS5kLG9IFKjSL7n2WIV2ZkfQTekgttqGl7AkQBEXAGGQGxkAoWPOP9fST6/lJGnXuLm2IKcX8Su0jNt/ZHmi+vy6L807NLnl1BnvIzfYDkW7H46fCjddU1dyBMcCp5g5QBBjwREYy5a7owqR3uzAMxUmggmWj7kk4QJ/teWoSYBO1B9k2Nohrg9WC/dKAGBGVQwA7LQUpQYLBuabrHr/8qMGs3yAxlmY8ezZ0CXWQdEIN2niMIBwZhJZ92aCNiORP1SQz+DfcOE/bGq+spj++jCJcMvO7Cu65A7EjdcY0XKSxT06UV6suMj8aTTXqIwAeKYGsezK64f+2AqR61hdhsVDL7u+BDq79zxyl1w84CVUPwgvLOW5NtL9D4202ntam7dRf68eAnVU6C3mdSCTGBKQOAcQkND7QacQ==; 5:oX1k39GrWGzaO9D+oqiLRTyWaXDDfJJhAb7XAXP6tF8g0M2IIyBr9cX4lnLc9T79BtR15A2NufTS96/rezdXf992NhPGn5IUfXeYkqUvmEtDzbyCAMfWaxVs0ALV3yvWU8BUBPSSayp6lT+CblXIDexURiAteTUcgKCC6++Lsn4=; 24:8/c5gD3VX2F6tvz1xcfZUQJOCXmP1+rEyjzbzxuu01mxYt3g81eAc8gSX7Cci+g9/5mzAOtRjhZ9ATOTCcxujmk95Q9EpLIxf9FWZ0zO7EE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR07MB2524; 7:MOBM6JzTj55EkDrJPdXMkCEhhZfIgqiWclRW/eTb6Tq+3DRVdDlR49sq+KjRu9+eXDdp52cEc+/Tv0KUCo+pHZd+aBTwEJ5Lgg0nvsIcOO6PtQouZ6T7ZzbCnR3nZZ/SrWGS+WgBrABPCIo40Xlg6I4N2xK2iIeFaiJovnjU7QhOVw58hlq2A3McX6k5R6oKLAfPzQnyVd8I2E4OiG9A0Ev1igNVm7kZKPJ17l6TnfCGfy4KmEmAivIZoHDVt5ln X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Apr 2018 04:39:05.7977 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 571f39c3-8b25-4cf4-61f6-08d59dd3d460 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR07MB2524 Subject: Re: [dpdk-dev] [PATCH v2 5/7] bpf: introduce basic RX/TX BPF filters 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: , X-List-Received-Date: Mon, 09 Apr 2018 04:39:10 -0000 -----Original Message----- > Date: Thu, 5 Apr 2018 12:51:16 +0000 > From: "Ananyev, Konstantin" > To: Jerin Jacob > CC: "dev@dpdk.org" > Subject: RE: [dpdk-dev] [PATCH v2 5/7] bpf: introduce basic RX/TX BPF > filters > > > Hi Jerin, > > > > > > > > > > > > > > > > > > > +/* > > > > > > > + * Marks given callback as used by datapath. > > > > > > > + */ > > > > > > > +static __rte_always_inline void > > > > > > > +bpf_eth_cbi_inuse(struct bpf_eth_cbi *cbi) > > > > > > > +{ > > > > > > > + cbi->use++; > > > > > > > + /* make sure no store/load reordering could happen */ > > > > > > > + rte_smp_mb(); > > > > > > > +} > > > > > > > + > > > > > > > +/* > > > > > > > + * Marks given callback list as not used by datapath. > > > > > > > + */ > > > > > > > +static __rte_always_inline void > > > > > > > +bpf_eth_cbi_unuse(struct bpf_eth_cbi *cbi) > > > > > > > +{ > > > > > > > + /* make sure all previous loads are completed */ > > > > > > > + rte_smp_rmb(); > > > > > > > > > > > > We earlier discussed this barrier. Will following scheme works out to > > > > > > fix the bpf_eth_cbi_wait() without cbi->use scheme? > > > > > > > > > > > > #ie. We need to exit from jitted or interpreted code irrespective of its > > > > > > state. IMO, We can do that by an _arch_ specific function to fill jitted memory with > > > > > > "exit" opcode(value:0x95, exit, return r0),so that above code needs to be come out i n anycase, > > > > > > on next instruction execution. I know, jitted memory is read-only in your > > > > > > design, I think, we can change the permission to "write" to the fill > > > > > > "exit" opcode(both jitted or interpreted case) for termination. > > > > > > > > > > > > What you think? > > > > > > > > > > Not sure I understand your proposal... > > > > > > > > If I understand it correctly, bpf_eth_cbi_wait() is used to _wait_ until > > > > eBPF program exits? Right? > > > > > > Kind off, but not only. > > > After bpf_eth_cbi_wait() finishes it is guaranteed that data-path wouldn't try > > > to access the resources associated with given bpf_eth_cbi (bpf, jit), so we > > > can proceed with freeing them. > > > > > > > . Instead of using bpf_eth_cbi_[un]use() > > > > scheme which involves the barrier. How about, > > > > > > > > in bpf_eth_cbi_wait() > > > > { > > > > > > > > memset the EBPF "program memory" with 0x95 value. Which is an "exit" and > > > > "return r0" EPBF opcode, Which makes program to terminate by it own > > > > as on 0x95 instruction, CPU decodes and it gets out from EPBF program. > > > > > > > > } > > > > > > > > In jitted case, it is not 0x95 instruction, which will be an arch > > > > specific instructions, We can have arch abstraction to generated > > > > such instruction for "exit" opcode. And use common code to fill the instructions > > > > to exit from EPBF program provided by arch code. > > > > > > > > Does that makes sense? > > > > > > There is no much point in doing it. > > > > It helps in avoiding the barrier on non x86 case. Right? > > Nope, I believe it doesn't, see below. > > > So it is useful > > thing. Right? and avoid the extra logic in fastpath increment/decrement > > "inuse" counters for all the archs. > > > > > What we need is a guarantee that after some point data-path wouldn't try to access > > > given bpf context, so we can destroy it. > > > > Is there any reason why you think, above proposed solution wont > > guarantee the termination eBPF program? > > > > -ie, > > 1)memset to "exit" instruction in eBPF memory > > Even when code is just interpreted (bpf_exec()) - there still be cases > when you need to synchronize execution thread with thread updating the code > (32bit systems, 16B LDDW instruction, etc.). > With JIT-ed code things will become much more complicated (icache, variable size instructions) > and I can't see how it could be done without extra synchronization between execute and update threads. > > > 2)Wait for N instruction cycles to terminate the program. > > There is no way to guarantee that execution would take exactly N cycles. > Execution thread could be preempted/interrupted, it could be executing syscall, > there could be CPU stall (access slow memory, cpu freq change, etc.). I agree. Things make worst with EBPF tail call etc. > > So even we'll solve all problems with 1) - it wouldn't buy us a safe solution. > > Actually quite a lot of research was done how to speedup slow/fast path synchronization > in user-space: > > https://lwn.net/Articles/573424/ > some theory beyond: > https://lttng.org/files/thesis/desnoyers-dissertation-2009-12-v27.pdf (chapter 6) > They even introduced a new syscall in Linux for these purposes: > http://man7.org/linux/man-pages/man2/membarrier.2.html > > I thought about something similar based on membarrier(), but it has > few implications: > 1. only latest linux kernels (4.14+) > 2. Not sure is it available on non x86 platforms. > 3. Need to measure real impact. > > Because of 1) and 2) we probably would need both mb() and membarrier() code paths. > Anyway - it is probably worth investigating for more generic solution, > but I suppose it is out of scope for that patch. Yes.