From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 1134D7F0C for ; Thu, 20 Nov 2014 15:07:02 +0100 (CET) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1XrSY3-0004Pl-RS; Thu, 20 Nov 2014 09:17:29 -0500 Date: Thu, 20 Nov 2014 09:17:27 -0500 From: Neil Horman To: Tapio Tallgren Message-ID: <20141120141727.GD2609@hmsreliant.think-freely.org> References: <20141120111727.GA2609@hmsreliant.think-freely.org> <6470390.sH3U320kkz@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: dev@dpdk.org Subject: Re: [dpdk-dev] Newbie question: compiling virtio-net-pmd v1.2 fails with dpdk 1.7 on a VM 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: Thu, 20 Nov 2014 14:07:02 -0000 On Thu, Nov 20, 2014 at 02:37:27PM +0200, Tapio Tallgren wrote: > On Thu, Nov 20, 2014 at 1:33 PM, Thomas Monjalon > wrote: > > > 2014-11-20 06:17, Neil Horman: > > > On Thu, Nov 20, 2014 at 09:14:35AM +0200, Tapio Tallgren wrote: > > > > Looks like a version conflict? Dpdk 1.7 should support virtio-pmd so > > what > > > > am I doing wrong? > > > > > > Nothing, its a bug. DPDK changed the API here with commit > > > 9aaccf1abdb2894ec23870e1d2199a657f85850e but it never got changed in the > > > virtio_user pmd. You need to modify the pmd like the other call sites > > have been > > > in the above commit. > > > > > > This is why those external pmds need to be merged into the dpdk tree. > > > > Yes, exactly. > > We'll see during 2.0 cycle how to merge them. The ideal plan is to keep > > only > > 1 implementation. > > > > In the meantime, patches are welcome. > > > > -- > > Thomas > > > > This looks like a purely cosmetic change? So, if the code compiles, then it > will also run correctly? > Not sure what you mean by that. It looks to me as though the second argument was removed. so if you remove that, yes the code should compile and run correctly. But you can't just do any old thing to make the code compile (e.g ifdef out the macro entirely, or some such), you still have to make the right change. Neil > > -- > -Tapio