[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200420162743.15847-1-olteanv@gmail.com>
Date: Mon, 20 Apr 2020 19:27:40 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: davem@...emloft.net, netdev@...r.kernel.org
Cc: idosch@...sch.org, allan.nielsen@...rochip.com,
horatiu.vultur@...rochip.com, alexandre.belloni@...tlin.com,
antoine.tenart@...tlin.com, andrew@...n.ch, f.fainelli@...il.com,
vivien.didelot@...il.com, joergen.andreasen@...rochip.com,
claudiu.manoil@....com, UNGLinuxDriver@...rochip.com,
alexandru.marginean@....com, xiaoliang.yang_1@....com,
yangbo.lu@....com, po.liu@....com, jiri@...lanox.com,
kuba@...nel.org
Subject: [PATCH net-next 0/3] Ocelot MAC_ETYPE tc-flower key improvements
From: Vladimir Oltean <vladimir.oltean@....com>
As discussed in the comments surrounding this patch:
https://patchwork.ozlabs.org/project/netdev/patch/20200417190308.32598-1-olteanv@gmail.com/
the restrictions imposed on non-MAC_ETYPE rules were harsher than they
needed to be. IP, IPv6, ARP rules can still be added concurrently with
src_mac and dst_mac rules, as long as those MAC address rules do not ask
for an offending EtherType.
For that to actually be supported, we need to parse the EtherType from
the flower classification rule first.
Vladimir Oltean (3):
net: mscc: ocelot: support matching on EtherType
net: mscc: ocelot: refine the ocelot_ace_is_problematic_mac_etype
function
net: mscc: ocelot: lift protocol restriction for flow_match_eth_addrs
keys
drivers/net/ethernet/mscc/ocelot_ace.c | 18 +++++++++++----
drivers/net/ethernet/mscc/ocelot_flower.c | 27 ++++++++++++++++-------
2 files changed, 33 insertions(+), 12 deletions(-)
--
2.17.1
Powered by blists - more mailing lists