[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20190530.125226.748439790590538564.davem@davemloft.net>
Date: Thu, 30 May 2019 12:52:26 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: jakub.kicinski@...ronome.com
Cc: horatiu.vultur@...rochip.com, alexandre.belloni@...tlin.com,
UNGLinuxDriver@...rochip.com, robh+dt@...nel.org,
mark.rutland@....com, ralf@...ux-mips.org, paul.burton@...s.com,
jhogan@...nel.org, linux-mips@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: [PATCH net-next v2 2/2] net: mscc: ocelot: Hardware ofload for
tc flower filter
From: Jakub Kicinski <jakub.kicinski@...ronome.com>
Date: Wed, 29 May 2019 15:18:44 -0700
> On Wed, 29 May 2019 12:26:20 +0200, Horatiu Vultur wrote:
>> +static int ocelot_flower_replace(struct tc_cls_flower_offload *f,
>> + struct ocelot_port_block *port_block)
>> +{
>> + struct ocelot_ace_rule *rule;
>> + int ret;
>> +
>> + if (port_block->port->tc.block_shared)
>> + return -EOPNOTSUPP;
>
> FWIW since you only support TRAP and DROP actions here (AFAICT) you
> should actually be okay with shared blocks. The problems with shared
> blocks start when the action is stateful (like act_police), because we
> can't share that state between devices. But for most actions which just
> maintain statistics, it's fine to allow shared blocks. HTH
Please update to remove this test Horatiu, thanks.
Powered by blists - more mailing lists