Re: [PATCH RFC] sched: split classification and enqueue

[Florian Westphal <fw@strlen.de>]

Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Wed, Jun 22, 2016 at 3:03 AM, Florian Westphal <fw@strlen.de> wrote:
> >
> > This (unfinished!) hack splits classification and enqueue into
> > two steps.
> >
> > Before enqueueing the packet and *before* acquiring the root qdisc lock,
> > the new qdisc ->classify() function is invoked.
> >
> > This function -- much like enqueue in the current scheme -- looks up
> > a child class and/or determines the next qdisc where the packet needs
> > to be handled via the classifier action subsystem.
> > Then it invokes the new ->classify() hook of the child, which can repeat
> > until the leaf qdisc is reached.
> 
> Then how is the atomicity guaranteed? One of the important
> purposes of the qdisc lock is to guarantee the atomicity of any
> change of in the whole hierarchy, i.e., qdisc/class/filter/action.

Not in this PoC, but I think that this could be solved e.g. by adding a
sequence counter that gets sampled pre-classify, we'd then only have to
check post-aquiring the root lock if its unchanged.  If not, some
class/filter, etc changed and we can just drop skb (or re-do the
classification, but I dislike such loops).

Only config changes would increment the counter, so it should not be
a lot of overhead.