Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <CAJ+HfNhxWFeKnn1aZw-YJmzpBuCaoeGkXXKn058GhY-6ZBDtZA@mail.gmail.com>
 <20210302195758.GQ2696@paulmck-ThinkPad-P72> <CAJ+HfNj-_P=LpkrUjxcOR73ffMXwsJ+o+zMTfmkiuH2zZ5XCLQ@mail.gmail.com>
 <20210302204157.GR2696@paulmck-ThinkPad-P72>
In-Reply-To: <20210302204157.GR2696@paulmck-ThinkPad-P72>
From:   =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= <bjorn.topel@gmail.com>
Date:   Tue, 2 Mar 2021 21:51:29 +0100
Message-ID: <CAJ+HfNhdgMTyfbeMsTsbhB_Pk6LW+2oB8=T0qWLgmM2q9_nkvQ@mail.gmail.com>
Subject: Re: XDP socket rings, and LKMM litmus tests
To:     paulmck@kernel.org
Cc:     bpf <bpf@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>,
        stern@rowland.harvard.edu, parri.andrea@gmail.com,
        Will Deacon <will@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>, boqun.feng@gmail.com,
        npiggin@gmail.com, dhowells@redhat.com, j.alglave@ucl.ac.uk,
        luc.maranget@inria.fr, akiyks@gmail.com, dlustig@nvidia.com,
        joel@joelfernandes.org,
        =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= <toke@redhat.com>,
        "Karlsson, Magnus" <magnus.karlsson@intel.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, 2 Mar 2021 at 21:41, Paul E. McKenney <paulmck@kernel.org> wrote:
>
> On Tue, Mar 02, 2021 at 09:24:04PM +0100, Bj=C3=B6rn T=C3=B6pel wrote:
> > On Tue, 2 Mar 2021 at 20:57, Paul E. McKenney <paulmck@kernel.org> wrot=
e:
> > >
> > > On Tue, Mar 02, 2021 at 07:46:27PM +0100, Bj=C3=B6rn T=C3=B6pel wrote=
:
> >
> > [...]
> >
> > >
> > > Before digging in too deeply, does the following simplification
> > > still capture your intent?
> > >
> >
> > Thanks for having a look, Paul!
> >
> > > P0(int *prod, int *cons, int *data)
> > > {
> > >     int p;
> > >     int cond =3D 0;
> > >
> > >     p =3D READ_ONCE(*prod);
> > >     if (p =3D=3D READ_ONCE(*cons))
> > >             cond =3D 1;
> >
> > With this, yes!
> >
> > >     if (cond) {
> > >         smp_mb();
> > >         WRITE_ONCE(*data, 1);
> > >         smp_wmb();
> > >         WRITE_ONCE(*prod, p ^ 1);
> > >     }
> > > }
> > >
> > > P1(int *prod, int *cons, int *data)
> > > {
> > >     int c;
> > >     int d =3D -1;
> > >     int cond =3D 0;
> > >
> > >     c =3D READ_ONCE(*cons);
> > >     if (READ_ONCE(*prod) =3D=3D c)
> > >             cond =3D 1;
> >
> > Hmm, this would not be the correct state transition.
> >
> > c=3D=3D1 && p=3D=3D1 would set cond to 1, right?
> >
> > I would agree with:
> >   c =3D READ_ONCE(*cons);
> >   if (READ_ONCE(*prod) !=3D c)
>
> Right you are!
>
> With that, it looks to me like LKMM is OK with removing the smp_mb().
> My guess is that the issue is that LKMM confines the effect of control
> dependencies to a single "if" statement, hence my reworking of your
> original.
>

Interesting!

I tried the acquire/release version:

P0(int *prod, int *cons, int *data)
{
    int p;
    int cond =3D 0;

    p =3D READ_ONCE(*prod);
    if (p =3D=3D READ_ONCE(*cons)) {
        WRITE_ONCE(*data, 1);
        smp_store_release(prod, p ^ 1);
    }
}

P1(int *prod, int *cons, int *data)
{
    int c;
    int d =3D -1;

    c =3D READ_ONCE(*cons);
    if (smp_load_acquire(prod) !=3D c) {
        d =3D READ_ONCE(*data);
        smp_store_release(cons, c ^ 1);
    }
}

and as with the previous example, restructuring the if-statement makes
"if (p =3D=3D READ_ONCE(*cons)) {" sufficient, instead of "if (p =3D=3D
smp_load_acquire(cons)) {".

Yay!


Bj=C3=B6rn


>                                                         Thanx, Paul
>
> > >
> > >     if (cond =3D=3D 1) {
> > >         smp_rmb();
> > >         d =3D READ_ONCE(*data);
> > >         smp_mb();
> > >         WRITE_ONCE(*cons, c ^ 1);
> > >     }
> > > }
> > >
> > >                                                         Thanx, Paul
> > >
> >
> > [...]
> >
> > Bj=C3=B6rn