Re: [RCU PATCH 00/14] Remove qdisc lock around ingress Qdisc

[Jamal Hadi Salim <jhs@mojatatu.com>]

On 03/10/14 13:03, John Fastabend wrote:
> This series drops the qdisc lock that is currently protecting the
> ingress qdisc. This can be done after the tcf filters are made
> lockless and the statistic accounting is safe to run without locks.
>
> To do this the classifiers are converted to use RCU. This requires
> updating each classifier individually to handle the new copy/update
> requirement and also to update the core list traversals. This is
> done in patches 2-11. This also makes the assumption that updates
> to the tables are infrequent in comparison to the packet per second
> being classified. On a 10Gbps running near line rate we can easily
> produce 12+ million packets per second so IMO this is a reasonable
> assumption. And the updates are serialized by RTNL.
>


I am in travel mode and dont have much cycles to do full review
and the patch set seems to be based on what we discussed earlier.
I worry on whether the assumption that table updates being
infrequent is going to cripple some of the use cases that have
made the interface powerful.  Cant find a presentation i did a
while back nor my data (i will look when i get back)- but one of the
things we prided on was ability to do extremely fast updates (both
latency and throughput) even in presence of datapath activity.
My comparison at the time was against netfilter (we were about
a magnitude faster).
So a good metric is to pick some classifier and action - then do
table updates with no traffic as a base metric and with your changes
after. Likewise with traffic.

BTW: does this mean there may be lack of sync between what the
control update is doing and what is being used in the datapath?

cheers,
jamal