Cong Wang <xiyou.wangc...@gmail.com> wrote: > On Wed, Jun 22, 2016 at 3:03 AM, Florian Westphal <f...@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.
