From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruce Richardson Subject: Re: DPDK mbuf pool in SR-IOV env and one RX/TX queue Date: Tue, 26 Jan 2016 12:18:58 -0800 Message-ID: <20160126201857.GB10276@bricha3-MOBL3> References: <20160123160930.GA16304@bricha3-MOBL3> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dev@dpdk.org To: Saurabh Mishra Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 33A749380 for ; Tue, 26 Jan 2016 21:19:11 +0100 (CET) Content-Disposition: inline In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Mon, Jan 25, 2016 at 04:15:28PM -0800, Saurabh Mishra wrote: > Hi Bruce -- > > >The sharing of the mbuf pool is not an issue, but sharing of rx/tx queues > is. > >The ethdev queues are not multi-thread safe, so to share a queue between > processes > >or threads, you need to put in locks or other access control mechanisms. > [This > >also implies a performance hit due to the locking] > >Regards, > >/Bruce > > Right. So now we have only one process to do rx/tx on queue 0 if we detect > that max queue support is 1. > > However, we have noticed that if our process, which does rx/tx, is not > primary, then we can't transmit the packet out with SR-IOV. > > Is there any specific limitation on SR-IOV (the vf driver in dpdk) that > only primary process should receive and transmit packets? > > In our model, we have an agent process which monitor links and another > process which does packet processing. If we make our agent process as > primary then our secondary process is not able to send the packets -- > rte_eth_tx_burst() succeed but recipient does not receive the packet. > > Thanks, > /Saurabh There should be no restrictions on RX/TX from secondary processes. /Bruce