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

Jakub Kicinski
2021-06-02T16:28:32Z

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.