From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6D2CBC2D0A3 for ; Thu, 29 Oct 2020 13:23:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1E8762076E for ; Thu, 29 Oct 2020 13:23:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726353AbgJ2NX3 (ORCPT ); Thu, 29 Oct 2020 09:23:29 -0400 Received: from mga14.intel.com ([192.55.52.115]:39014 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725601AbgJ2NX2 (ORCPT ); Thu, 29 Oct 2020 09:23:28 -0400 IronPort-SDR: 1k0riG6/nNaY/WZzBsdzHHr/bnl1aDX5poEBFaLciix687WWTcqb5FnENiGekIltPXcmaLSUa0 rmj2X6NEgGDg== X-IronPort-AV: E=McAfee;i="6000,8403,9788"; a="167649001" X-IronPort-AV: E=Sophos;i="5.77,430,1596524400"; d="scan'208";a="167649001" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Oct 2020 06:23:27 -0700 IronPort-SDR: PLdLnRNYv65oF+2MXQgfmFKTthOo6GGy31skimlKhrSgzO1dxUUp9kiv8xMIOZBZdfY8ibdfbg xjeYEEJj/ZYQ== X-IronPort-AV: E=Sophos;i="5.77,430,1596524400"; d="scan'208";a="323703403" Received: from rondarha-mobl1.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.212.42.193]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Oct 2020 06:23:26 -0700 Date: Thu, 29 Oct 2020 06:23:26 -0700 Message-ID: <87o8klf9o1.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Vincent Whitchurch Cc: Arnd Bergmann , Sherry Sun , "Dutt, Sudeep" , dl-linux-imx , "linux-kernel@vger.kernel.org" , "hch@infradead.org" , "kishon@ti.com" , "lorenzo.pieralisi@arm.com" , "gregkh@linuxfoundation.org" Subject: Re: [PATCH V3 2/4] misc: vop: do not allocate and reassign the used ring In-Reply-To: <20201029100727.trbppgbusd5vogpz@axis.com> References: <20201023092650.GB29066@infradead.org> <20201027062802.GC207971@kroah.com> <20201027151106.e4skr6dsbwvo4al6@axis.com> <93bd1c60ea4d910489a7592200856eaf8022ced0.camel@intel.com> <20201029100727.trbppgbusd5vogpz@axis.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 29 Oct 2020 03:07:27 -0700, Vincent Whitchurch wrote: > > On Wed, Oct 28, 2020 at 04:50:36PM +0100, Arnd Bergmann wrote: > > I think we should try to do something on top of the PCIe endpoint subsystem > > to make it work across arbitrary combinations of host and device > > implementations, > > and provide a superset of what the MIC driver, (out-of-tree) Bluefield endpoint > > driver, and the NTB subsystem as well as a couple of others used to do, > > each of them tunneling block/network/serial/... over a PCIe link of some > > sort, usually with virtio. > > VOP is not PCIe-specific (as demonstrated by the vop-loopback patches I > posted a while ago [1]), and it would be a shame for a replacement to be > tied to the PCIe endpoint subsystem. There are many SOCs out there > which have multiple Linux-capable processors without cache-coherency > between them. VOP is (or should I say was since I guess it's being > deleted) the closest we have in mainline to easily get generic virtio > (and not just rpmsg) running between these kind of Linux instances. If > a new replacement framework were to be PCIe-exclusive then we'd have to > invent one more framework for non-PCIe links to do pretty much the same > thing. > > [1] https://lore.kernel.org/lkml/20190403104746.16063-1-vincent.whitchurch@axis.com/ It may be possible to use VOP in other instances but it was optimized for PCIe. The rings were specifically placed to avoid doing reads across PCIe and only do writes across PCIe.