From mboxrd@z Thu Jan  1 00:00:00 1970
Content-Type: multipart/mixed; boundary="===============8342631987143614346=="
MIME-Version: 1.0
From: Harris, James R <james.r.harris at intel.com>
Subject: Re: [SPDK] SPDK Ring Enqueue/Dequeue Issue
Date: Wed, 19 Sep 2018 19:07:15 +0000
Message-ID: <8C6480B2-5BD1-42D8-970F-DF40372A8A83@intel.com>
In-Reply-To: CANvN+eksjq5WQAAw+vMvyy6JH0cx=ZwE=PXEM2iio7RqyHzH6Q@mail.gmail.com
List-ID: <spdk@lists.01.org>
To: spdk@lists.01.org

--===============8342631987143614346==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable



On 9/19/18, 11:37 AM, "SPDK on behalf of Andrey Kuzmin" <spdk-bounces(a)lis=
ts.01.org on behalf of andrey.v.kuzmin(a)gmail.com> wrote:

    On Wed, Sep 19, 2018 at 9:13 PM John Barnard <john.barnard(a)broadcom.c=
om>
    wrote:
    =

<snip>

    >
    > It seems that the spdk_ring_enqueue function calls
    > rte_ring_mp_enqueue_bulk(), while spdk_ring_dequeue function calls
    > rte_ring_sc_dequeue_burst().  When we change it to call
    > ret_ring_mp_dequeue_burst(), the problem went away.  So my question i=
s, why
    > this difference in the rte calls made by the SPDK?  Is this a bug or =
on
    > purpose?  Also, we noticed that there is no ring create flag (in
    > include/spdk/env.h) for multi-producer, multi-consumer (i.e.
    > SPDK_RING_TYPE_MP_MC), although it doesn't seem to matter if we pass =
the
    > SPDK_RING_TYPE_MP_SC flag to  spdk_ring_create() (i.e. it's the call =
to
    > rte_ring_mp_dequeue_burst that's critical).  Is there a reason this f=
lag
    > was left out?
    >
    =

    The two issues above are interrelated. SPDK seemingly does not care for
    MP/MC rings, so it neither defines the flag to create the respective ri=
ng
    type, nor appreciates this ring type under ring_dequeue (for enqueue, it
    uses MP flavor which works for SP case as well).
    =

    The definitive answer as to why belongs to the SPDK team, while my gues=
s is
    that rings in SPDK are primarily (and solely, to the best of my knowled=
ge)
    for passing messages between SPDK threads where  MP/MC scenario does not
  apply.

Andrey is correct.  There hasn=E2=80=99t been a use case for MP/MC rings in=
 SPDK yet.  Rings are primarily used today for passing messages to a specif=
ic reactor =E2=80=93 each reactor has its own ring (so it=E2=80=99s single =
consumer) but any thread may post messages to it.

I see no reason to not add MP/MC support if it=E2=80=99s needed for NVMe-oF=
 FC.

John =E2=80=93 is this something you=E2=80=99d like to tackle?

-Jim


--===============8342631987143614346==--