Hi, Feifei
.. snip..
>
> I can understand you worry that if there is no 'wmb at last', when agent_1
> leave the locked section, agent_2 still may observe unchanged global cache.
>
> However, when agent_2 take a lock and get(new MR) in time slot 7(Fig.1), it
> means
> agent_1 has finished updatin
Hi, Feifei
..ship..
>
> If I understand correctly, your meaning is that if without wmb, maybe other
> agents observe changed "dev_gen", but they also observe unchanged
> "global" cache.
> This can be defined as memory inconsistent state.
>
> Fig1
>
Hi, Feifei
Please, see below.
> -Original Message-
> From: Feifei Wang
> Sent: Saturday, May 8, 2021 6:13
> To: Slava Ovsiienko ; Matan Azrad
> ; Shahaf Shuler
> Cc: dev@dpdk.org; nd ; sta...@dpdk.org; Ruifeng Wang
> ; nd ; nd
> Subject: 回复: [PATCH v1 3/4] net/mlx5: fix rebuild bug for
Hi, Feifei
We should consider the locks in your scenario - it is crucial for the complete
model description:
How agent_1 (in your terms) rebuilds global cache:
1a) lock()
1b) rebuild(global cache)
1c) update(dev_gen)
1d) wmb()
1e) unlock()
How agent_2 checks:
2a) check(dev_gen) (assume positi
Hi, Feifei
Sorry, I do not follow why we should get rid of the last (after dev_gen update)
wmb.
We've rebuilt the global cache, we should notify other agents it's happened and
they should flush local caches. So, dev_gen change should be made visible
to other agents to trigger this activity and th
Hi, Feifei
In my opinion, there should be 2 barriers:
- after global cache update/before altering dev_gen, to ensure the correct
order
- after altering dev_gen to make this change visible for other agents and to
trigger local cache update
With best regards,
Slava
> -Original Message-
Hi, Feifei
Please, see below
> > Hi, Feifei
> >
> > Sorry, I do not follow what this patch fixes. Do we have some
> > issue/bug with MR cache in practice?
>
> This patch fixes the bug which is based on logical deduction, and it doesn't
> actually happen.
>
> >
> > Each Tx queue has its ow
Hi, Feifei
Sorry, I do not follow what this patch fixes. Do we have some issue/bug with MR
cache in practice?
Each Tx queue has its own dedicated "local" cache for MRs to convert buffer
address in mbufs being transmitted
to LKeys (HW-related entity handle) and the "global" cache for all MR
reg
'dev_gen' is a variable to inform other cores to flush their local cache
when global cache is rebuilt.
However, if 'dev_gen' is updated after global cache is rebuilt, other
cores may load a wrong memory region lkey value from old local cache.
Timeslotmain core worker core
9 matches
Mail list logo
