From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail5.wrs.com (mail5.windriver.com [192.103.53.11]) by dpdk.org (Postfix) with ESMTP id 11CACCFD8 for ; Fri, 17 Mar 2017 11:15:57 +0100 (CET) Received: from ALA-HCB.corp.ad.wrs.com (ala-hcb.corp.ad.wrs.com [147.11.189.41]) by mail5.wrs.com (8.15.2/8.15.2) with ESMTPS id v2HAFsDb005240 (version=TLSv1 cipher=AES128-SHA bits=128 verify=OK); Fri, 17 Mar 2017 03:15:55 -0700 Received: from ALA-MBC.corp.ad.wrs.com ([fe80::fcbe:9b7:1141:89a1]) by ALA-HCB.corp.ad.wrs.com ([147.11.189.41]) with mapi id 14.03.0294.000; Fri, 17 Mar 2017 03:15:55 -0700 From: "Legacy, Allain" To: Thomas Monjalon , "WILES, ROGER" , Jason Wang , "Michael S. Tsirkin" CC: Vincent JARDIN , Stephen Hemminger , "O'Driscoll, Tim" , "YIGIT, FERRUH" , "dev@dpdk.org" , "Jolliffe, Ian" , Markus Armbruster , Stefan Hajnoczi Thread-Topic: [dpdk-dev] [PATCH v4 00/17] Wind River Systems AVP PMD vs virtio? - ivshmem is back Thread-Index: AQHSnq7d7Tt7RrtBC0qXfm0RNwt8PqGYnfEAgAAFpwCAAAY0AIAAhLkA//+hHYA= Date: Fri, 17 Mar 2017 10:15:53 +0000 Message-ID: <70A7408C6E1BFB41B192A929744D8523968F2B97@ALA-MBC.corp.ad.wrs.com> References: <1488414008-162839-1-git-send-email-allain.legacy@windriver.com> <9242BBFE-279B-46E3-BC04-62F1FE897824@intel.com> <3140337.WIddM6FeqF@xps13> In-Reply-To: <3140337.WIddM6FeqF@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.224.140.166] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v4 00/17] Wind River Systems AVP PMD vs virtio? - ivshmem is back 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: Fri, 17 Mar 2017 10:15:58 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Friday, March 17, 2017 4:49 AM <...> > I think there is one interesting technological point in this thread. > We are discussing about IVSHMEM but its support by Qemu is confused. > This feature is not in the MAINTAINERS file of Qemu. > Please Qemu maintainers, what is the future of IVSHMEM? I need to clarify a technical point. AVP is not ivshmem; at least not in t= he strict sense of the term. We initially started out using ivshmem as-is= but then we needed to fork from that in order to add functionality that we= needed to better integrate with our solution. AVP is now a separate Wind = River specific extension completely independent of any past ivshmem impleme= ntation. I used the term ivshmem in the documentation to provide context t= o the reader to understand, by comparison, what type of shared memory model= we are using. I can remove that reference if it leads to confusion or a d= esire to make direct comparisons with ivshmem.