On Thu, Sep 3, 2020 at 1:40 AM Paolo Abeni <pab...@redhat.com> wrote: > > On Wed, 2020-09-02 at 22:01 -0700, Cong Wang wrote: > > Can you test the attached one-line fix? I think we are overthinking, > > probably all > > we need here is a busy wait. > > I think that will solve, but I also think that will kill NOLOCK > performances due to really increased contention.
Yeah, we somehow end up with more locks (seqlock, skb array lock) for lockless qdisc. What an irony... ;) > > At this point I fear we could consider reverting the NOLOCK stuff. > I personally would hate doing so, but it looks like NOLOCK benefits are > outweighed by its issues. I agree, NOLOCK brings more pains than gains. There are many race conditions hidden in generic qdisc layer, another one is enqueue vs. reset which is being discussed in another thread. Thanks.
