From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from compass.polito.it (compass.polito.it [130.192.55.110]) by dpdk.org (Postfix) with ESMTP id 646538D8E for ; Fri, 16 Oct 2015 15:16:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by compass.polito.it (Postfix) with ESMTP id 380AB1000D0 for ; Fri, 16 Oct 2015 15:16:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= studenti.polito.it; h=content-type:content-type:cc:to:from:from :subject:subject:message-id:date:date:references:in-reply-to :received:mime-version:received:received:received; s=y2k10; t= 1445001364; bh=xtkj0JzYwm4NlkT6fl6X/JAAKksoL5PW6QOfRIxVxPg=; b=l Rqz7wgcUTOucghCnjSjFR+5unupC9raZdriBepXomufVXDhEDRpau1+kiFRce6/s RaO51b5vE4IAsgTbmNpeyl2jFAKDctRaPtLLe6iNq9vC3xjn/kc3zpxa9/RT/wQP fyTGIbJVNQllemEvabpppWZyZ/doBJy9ymQPl4iBCo= X-Virus-Scanned: amavisd-new at studenti.polito.it Received: from compass.polito.it ([127.0.0.1]) by localhost (compass.polito.it [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id BoLuUFEzd0ul for ; Fri, 16 Oct 2015 15:16:04 +0200 (CEST) Received: from mail-lf0-f47.google.com (mail-lf0-f47.google.com [209.85.215.47]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: s203403@studenti.polito.it) by compass.polito.it (Postfix) with ESMTPSA id AD0AA1000BD for ; Fri, 16 Oct 2015 15:16:04 +0200 (CEST) Received: by lffv3 with SMTP id v3so79909167lff.0 for ; Fri, 16 Oct 2015 06:16:04 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.25.147.209 with SMTP id v200mr5365124lfd.22.1445001364318; Fri, 16 Oct 2015 06:16:04 -0700 (PDT) Received: by 10.25.77.197 with HTTP; Fri, 16 Oct 2015 06:16:04 -0700 (PDT) In-Reply-To: References: Date: Fri, 16 Oct 2015 15:16:04 +0200 Message-ID: From: =?UTF-8?Q?Mauricio_V=C3=A1squez?= To: "Burakov, Anatoly" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] Why rte_eal_ivshmem_obj_initd() does not add memory pools to rte_mempool_tailq list? X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 13:16:06 -0000 Hi Anatoly, Thank you very much for your answer, it clarifies it for me. I absolutely agree with you that adding mempools support should not be implemented until a solution for mempool cache corruption is found. Mauricio, On 16 October 2015 at 15:00, Burakov, Anatoly wrote: > Hi Mauricio > > > Dear DPDK community, > > > > Some time ago I was trying to map a memory pool into a guest using > > IVSHMEM as described here: > > > > http://comments.gmane.org/gmane.comp.networking.dpdk.devel/17779 > > > > After some time I decided to review the code of eal_ivshmem.c, I notice= d > > that in the function rte_eal_ivshmem_obj_init the rings are added to th= e > > rte_ring_tailq list, but for memory pools there is not a similar > procedure. > > My question is why it does not exist such procedure? Is there any reaso= n > or > > is it just missing? > > > > If it is just missing I could propose a implementation for it, > > > > Thank you very much for your attention, > > > > Mauricio V=C3=A1squez > > Sharing mempools over IVSHMEM is not supported because all sorts of > strange things start to happen when you consider that mempool caches (whi= ch > are not thread safe) are part of the picture. The only way to even work > with mempools over IVSHMEM without things horribly breaking would be to > either always watch your coremasks (which is prone to user error) or > disable mempool caches (which slows things down). This is the reason > sharing mempools over IVSHMEM was never supported. > > Technically, there is nothing stopping you to implement it yourself - all > you have to do is to add a wrapper that looks for their memzones (like we > have for rings), and add an auto-discovery mechanism to the EAL IVSHMEM > code (again, like we have for rings). However, unless things I mentioned > aren't a problem anymore for whatever reason, I would be very reluctant t= o > ack a patch adding mempools support to IVSHMEM code. > > Thanks, > Anatoly >