From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-f53.google.com (mail-vk0-f53.google.com [209.85.213.53]) by dpdk.org (Postfix) with ESMTP id F1F939A8D for ; Thu, 28 Jan 2016 05:39:26 +0100 (CET) Received: by mail-vk0-f53.google.com with SMTP id e64so17599568vkg.0 for ; Wed, 27 Jan 2016 20:39:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XKpZhGJJRtRDN3npPRXTmVggiX+p6as5FtI5p/hqUN8=; b=cqXkorj8y3+pS41lpqNjdtYi1k5YOqMZlu1YUB6g3qCX3nDEheJ/b/YsZtxX90TjSD TuNgZdQl13qNJtV2m76Q9/gAEtfLmyqzUBGgHupNle3tfejdX1xwAIQIchOs5fYf8DS8 npjkBeCGY2oVzjcTt6g2VYuqU5OVdB1heaPvfhvq0MbS/Ou6qjCFyc27qU8gFlk192r6 A6//9ip+gaBDru6LdRIPS7yK5aCrPrR3TVKZY1cEV6hW9bmuY8Dux8mxIeEVxr18SoSa IJz1TEJgeL29CnQGlaH4VIrCZo726ZQX72DaBAVzpJsPIJWsO6kGG/P8sfFcRaYKNY3G n61w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XKpZhGJJRtRDN3npPRXTmVggiX+p6as5FtI5p/hqUN8=; b=IMpb2wV6IfIOIeOhHYLC5mA31S8Q130UFA/6ob/705RIEN4BqGiECgHsfKb5g8rFpc mXMKFrBTKd01pR6UMr44ZXyVBMwVpROa6vnz1fj63ORuwnNmgt267oFxJziWXUYaMgRw b9lan349tmgFVtZxUxhgK9UCRBxHkmLd5Zj7DWAZVyOdeXfbQhAuUZvLd9ToqQZS3m9f 4JGsrCArPRftywsqIMOSt5npx13qovlMKd7W4CDzXtRs8XmGr67xzb7u7chbJFres49T +SGyx05eLUoLXsdvOgD+hg37YRtR+a99Ls357oxjTMF6XkXA0OhKhccv1r6LFI7oaeI2 r7Rw== X-Gm-Message-State: AG10YOSQ7cDrG8ZfGyB1LxDL16g5sNAsyxJCVzwlr7ul3TAiiMreuvpyInn8ZIKXTPFZBvnNBAUq5Ja8ywZJng== MIME-Version: 1.0 X-Received: by 10.31.178.146 with SMTP id b140mr648878vkf.108.1453955966480; Wed, 27 Jan 2016 20:39:26 -0800 (PST) Received: by 10.31.152.208 with HTTP; Wed, 27 Jan 2016 20:39:26 -0800 (PST) Received: by 10.31.152.208 with HTTP; Wed, 27 Jan 2016 20:39:26 -0800 (PST) In-Reply-To: <20160126201857.GB10276@bricha3-MOBL3> References: <20160123160930.GA16304@bricha3-MOBL3> <20160126201857.GB10276@bricha3-MOBL3> Date: Wed, 27 Jan 2016 20:39:26 -0800 Message-ID: From: Saurabh Mishra To: Bruce Richardson Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: dev@dpdk.org Subject: Re: [dpdk-dev] DPDK mbuf pool in SR-IOV env and one RX/TX queue 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, 28 Jan 2016 04:39:27 -0000 Any clues or hint on how to debug this kind of problem on SR-IOV? Only primary can send packet but secondary process couldn't. I have verified host's qprc and qptc counters on PF and they do increment. SR-IOV with DPDK seems more challenging than PCI pass through of whole NIC. Saurabh On Jan 26, 2016 12:19 PM, "Bruce Richardson" wrote: > 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 >