lkml.org 
[lkml]   [2021]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Linuxarm] Re: [PATCH net-next 2/3] net: sched: implement TCQ_F_CAN_BYPASS for lockless qdisc
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.

\
 
 \ /
  Last update: 2021-06-02 18:29    [W:0.069 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site