[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+h21hr==OStFfgaswzU7HtFg_bHZPoZD5JTQD+-e4jWwZYWHQ@mail.gmail.com>
Date: Fri, 30 Aug 2019 13:11:11 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc: Florian Fainelli <f.fainelli@...il.com>,
Vivien Didelot <vivien.didelot@...il.com>,
Andrew Lunn <andrew@...n.ch>,
"David S. Miller" <davem@...emloft.net>,
Vinicius Costa Gomes <vinicius.gomes@...el.com>,
vedang.patel@...el.com, Richard Cochran <richardcochran@...il.com>,
weifeng.voon@...el.com, jiri@...lanox.com, m-karicheri2@...com,
Jose.Abreu@...opsys.com,
Ilias Apalodimas <ilias.apalodimas@...aro.org>,
Jamal Hadi Salim <jhs@...atatu.com>,
xiyou.wangcong@...il.com, netdev <netdev@...r.kernel.org>
Subject: Re: [RFC PATCH v2 net-next 00/15] tc-taprio offload for SJA1105 DSA
Hi Jakub,
On Fri, 30 Aug 2019 at 04:21, Jakub Kicinski
<jakub.kicinski@...ronome.com> wrote:
>
> On Fri, 30 Aug 2019 03:46:20 +0300, Vladimir Oltean wrote:
> > - Configuring the switch over SPI cannot apparently be done from this
> > ndo_setup_tc callback because it runs in atomic context. I also have
> > some downstream patches to offload tc clsact matchall with mirred
> > action, but in that case it looks like the atomic context restriction
> > does not apply.
>
> This sounds really surprising ndo_setup_tc should always be allowed to
> sleep. Can the taprio limitation be lifted somehow?
I need to get more familiar with the taprio internal data structures.
I think you're suggesting to get those updated to a consistent state
while under spin_lock_bh(qdisc_lock(sch)), then call ndo_setup_tc from
outside that critical section?
Also, I just noticed that I introduced a bug in taprio_disable_offload
with my reference counting addition. The qdisc can't just pass stack
memory to the driver, now that it's allowing it to keep it. So
definitely the patch needs more refactoring.
Thanks,
-Vladimir
Powered by blists - more mailing lists