From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <saurabh.globe@gmail.com>
Received: from mail-vk0-f48.google.com (mail-vk0-f48.google.com
 [209.85.213.48]) by dpdk.org (Postfix) with ESMTP id 538565A9B
 for <dev@dpdk.org>; Tue, 26 Jan 2016 01:15:29 +0100 (CET)
Received: by mail-vk0-f48.google.com with SMTP id k1so83336328vkb.2
 for <dev@dpdk.org>; Mon, 25 Jan 2016 16:15:29 -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=7ZDCTbL84UE68N7r41zvI2dszyOER7rLmuHE/zjVwN8=;
 b=zENYoTYdoi6QVnphvqH4kxPglCYSjcmQeQouXivVc11RQzB9uXetSc0XA5vZSj2f2y
 0hI+xhRN+Q6gbEcB8oEHtR/gB+cTezpqfWtRzQw+ohsrEHYYhE6B5PgdVzRjqT+hVvYR
 nA+djZiulHsQWSU1+UbHYjCuLLjK8+Pda2ID1AcqsSNC1oUO95lVg0I7kPe34/eM43Mv
 F3PMEcWz2JM2aHAVZLbhwgwdHet05FH4NAfUedh0vU/2k7Nw/V2iA7x9mGfKN9AmJVxu
 AeJWtnqgWZdC4Qn5fXWhPhtPjXsBeLaK+3o2aH7UjP3SrCM0Hi3IwIlUw4W6HVEMKfn8
 hWtg==
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=7ZDCTbL84UE68N7r41zvI2dszyOER7rLmuHE/zjVwN8=;
 b=eHogggjChNRRpP5Zz5RO8+Ic/ydulf4crZdu9yFJhu+nymlbGC3PG/ZqMwnQrPk4Ff
 q7TZ3EcYvss+wyMAYzkGqNQsMPwG4mVuCK1xaJyKy8XHRCsNs8vLIT2jXt3NyGOdV4Jb
 BHtPRU69000pGUNq58d//NNemn0ysByO2FeZNClorO3VAsL4ABkuIjqNFAo/NXnFwEgQ
 JumLfyybDyyigusq6AUengg0yyij8/HZWIrH8aIaEm7OeE0fdDSGRKtnV9hbKFwY48VN
 TZEwItV8IF0iPECGCBpBHrnCY0lZB1YbPz2FNkbO8uI0ZqA+lskEhRz9Ak3yKDhAmUfn
 lhFA==
X-Gm-Message-State: AG10YOSYRvIYTpQj/vVJ1K4P5ispRkUoaQjL1gbzLNsZKAmluxdWnwEeAX6Ixfej1x3U54mrISFsh6Mc9vAECQ==
MIME-Version: 1.0
X-Received: by 10.31.54.23 with SMTP id d23mr12526806vka.25.1453767328438;
 Mon, 25 Jan 2016 16:15:28 -0800 (PST)
Received: by 10.31.152.208 with HTTP; Mon, 25 Jan 2016 16:15:28 -0800 (PST)
In-Reply-To: <20160123160930.GA16304@bricha3-MOBL3>
References: <CAMnwyJ0o9GtjOPxN_=RKHWTKgkeUSeuAFyc7By8KA3rRwnKwNg@mail.gmail.com>
 <20160123160930.GA16304@bricha3-MOBL3>
Date: Mon, 25 Jan 2016 16:15:28 -0800
Message-ID: <CAMnwyJ24vF_RtVXqxb5vCasF=5-+qDfDWhOyHCt5EwMTRtEhNA@mail.gmail.com>
From: Saurabh Mishra <saurabh.globe@gmail.com>
To: Bruce Richardson <bruce.richardson@intel.com>
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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jan 2016 00:15:29 -0000

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

On Sat, Jan 23, 2016 at 8:09 AM, Bruce Richardson <
bruce.richardson@intel.com> wrote:

> On Thu, Jan 21, 2016 at 08:35:20PM -0800, Saurabh Mishra wrote:
> > Hi,
> >
> >
> > Is it possible for two or more processes to share the same mbuf_pool in
> > SR-IOV with single rx/tx queue?
> >
> >
> 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
>
>