DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] Strange cache sync problem(?) with reading mbuf
       [not found] <1405941610.58386.1561692731231.ref@mail.yahoo.com>
@ 2019-06-28  3:32 ` P Smith
  0 siblings, 0 replies; only message in thread
From: P Smith @ 2019-06-28  3:32 UTC (permalink / raw)
  To: Dev

Hello all,                 I am aware that this is some caching/synchronization problem but for some reason despite using the barrier macros it does not seem to go away.What makes it go away though is to give a rte_delay of 100us and re-reading the value again like so:
        cons_rx_buf = &rxr->rx_buf_ring[cons];
        mbuf = cons_rx_buf->mbuf;
        rte_smp_mb();
        if (mbuf == NULL) {
                int cnt = 0;
                RTE_LOG(ERR, PMD, "mbuf = NULL cons = %d\n", cons);
                do {
                        rte_delay_us(100);
                        cons_rx_buf = &rxr->rx_buf_ring[cons];
                        mbuf = cons_rx_buf->mbuf;
                } while(mbuf == NULL && ++cnt <= 10);
                RTE_LOG(ERR, PMD, "mbuf = %p cnt = %d\n", mbuf, cnt);
        }

Invariably i see the 'mbuf = NULL' print and then post 1 iteration of the while loop the 'mbuf' is not NULL (correct value as expected) and it moves on smoothly....Clearly this seems like some cache synchronization issue and i thought the smp_wb() primitives should have solved it? 
Any other better ways to fix this other than this rte_delay_us() ?
ThanksSmith


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2019-06-28  3:32 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <1405941610.58386.1561692731231.ref@mail.yahoo.com>
2019-06-28  3:32 ` [dpdk-dev] Strange cache sync problem(?) with reading mbuf P Smith

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).