netdev - Re: [RFC Patch net-next] net_sched: make classifying lockless on ingress

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <52B70CC2.9080805@mojatatu.com>
Date:	Sun, 22 Dec 2013 11:01:06 -0500
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	John Fastabend <john.fastabend@...il.com>
CC:	John Fastabend <john.r.fastabend@...el.com>,
	Cong Wang <xiyou.wangcong@...il.com>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [RFC Patch net-next] net_sched: make classifying lockless on
 ingress

On 12/21/13 18:09, John Fastabend wrote:

>
> I solved this by making them per CPU and synchronizing when I hit
> an operation that required sync'ing them. Going forward if folks
> have the time to write SMP aware qdisc's that work with eventually
> consistent counters that would be great.
>

I think what you describe is reasonable as well. Need to weigh pro/con
of both.

> You could make this fully generic by having a classifer to match
> the cpu id and then forwarding the skb to a qdisc based on the
> cpu_id.
>

Indeed. More a "generic stateless metadata" classifier which may
look at more than just cpu id to make the systolic decision.
Probably at pre-enqueu that you had.
I would assume the amount of config update on such a table would be
very very minimal - so RCU would do well.
If someone wants more deeper lookup, then a tc classifier would make
more sense. But by default the generic stateless classifier maybe
sufficient.

> Then per-netdev-ingress-per-cpu is really just a configured policy.
> If we wanted to make it the default configuration that would be
> fine.
>

Perhaps thats just defensive talk on my part when people say "qdiscs
are slow". No - netdevs are slow. Rephrase: Netdevs are shared across
CPUs, you MUST lock. Locks create cache misses etc.
As an example, I dont know why something like RPS could not have 
benefited from the rich classifier-action if someone wanted it to.
So there may still be need for per-netdev-ingress-per-cpu.

cheers,
jamal
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html