Re: [Linuxarm] Re: [PATCH net-next 2/3] net: sched: implement TCQ_F_CAN_BYPASS for lockless qdisc

[Jakub Kicinski]

On Wed, 2 Jun 2021 09:21:01 +0800 Yunsheng Lin wrote:
> >> For the MISSING clearing in pfifo_fast_dequeue(), it seems it
> >> looks like the data race described in RFC v3 too?
> >>
> >>       CPU1                 CPU2               CPU3
> >> qdisc_run_begin(q)          .                  .
> >>         .              MISSED is set           .
> >>   MISSED is cleared         .                  .
> >>     q->dequeue()            .                  .
> >>         .              enqueue skb1     check MISSED # true
> >> qdisc_run_end(q)            .                  .
> >>         .                   .         qdisc_run_begin(q) # true
> >>         .            MISSED is set      send skb2 directly  
> > 
> > Not sure what you mean.  
> 
>        CPU1                 CPU2               CPU3
>  qdisc_run_begin(q)          .                  .
>          .              MISSED is set           .
>    MISSED is cleared         .                  .
>    another dequeuing         .                  .
>          .                   .                  .
>          .              enqueue skb1  nolock_qdisc_is_empty() # true
>  qdisc_run_end(q)            .                  .
>          .                   .         qdisc_run_begin(q) # true
>          .                   .          send skb2 directly
>          .               MISSED is set          .
> 
> As qdisc is indeed empty at the point when MISSED is clear and
> another dequeue is retried by CPU1, MISSED setting is not under
> q->seqlock, so it seems retesting MISSED under q->seqlock does not
> seem to make any difference? and it seems like the case that does
> not need handling as we agreed previously?

Right, this case doesn't need the re-check under the lock, but pointed
out that the re-queuing case requires the re-check.