netdev - Re: [PATCH v2 net-next 0/7] net_sched: act: lockless operation

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] [day] [month] [year] [list]

Message-ID: <CANn89iLaZ5uECv0susGeX4XFF_LN4TzVTegqoqgf36m0eTZJzA@mail.gmail.com>
Date:	Mon, 6 Jul 2015 14:17:36 +0200
From:	Eric Dumazet <edumazet@...gle.com>
To:	Jamal Hadi Salim <jhs@...atatu.com>
Cc:	"David S. Miller" <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>,
	Alexei Starovoitov <ast@...mgrid.com>,
	John Fastabend <john.fastabend@...il.com>,
	Eric Dumazet <edumazet@...il.com>
Subject: Re: [PATCH v2 net-next 0/7] net_sched: act: lockless operation

On Mon, Jul 6, 2015 at 2:12 PM, Jamal Hadi Salim <jhs@...atatu.com> wrote:

> on mirred:
> The main thing that is read-write is the stats. lastuse timestamp
> as well, but that one doesnt have to be accurate (used mainly
> to help decide when to flush out policies). so the lock around
> all that code is not necessary.
>
> BTW: I was wondering based on what you said earlier on false sharing
> if tcf_common can be re-arranged to avoid that?

Not really : You would still have a stall on lastuse ultimately, even
if it sits in a cache line of its own.

I mentioned that it shared a cache line to explain with "perf" was
showing the stall on reading another field.


>
> For mirred, you may have to add for overlimit stat in the common
> structure (we should really increment drop stats when we return
> TC_ACT_SHOT).
>
> Having said that: we want to maintain the fact that an action
> instance (based on index) can be used across different policies.
> i dont see any issue with the way you are proceeding for that
> to continue to work. i.e i can say something like:
> - create an action to redirect or mirror to port blah index 10
> - create filter one on eth1 with 1 of the actions being mirred index 10
> - create filter two on eth0 with 1 of the actions being mirred index 10

I do not see any issues either.

>
> On IFB:
> we use tasklets originally to avoid re-ordering. I think tasklets would
> still be useful to keep, with each tied to a queue?

Sure. We do not care about reorders if packets were delivered to
different RX queues.
--
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