| Message ID | 20200602051828.5734-1-xiaoliang.yang_1@nxp.com |
|---|---|
| Headers | show |
| Series | net: ocelot: VCAP IS1 and ES0 support | expand |
Hi Xiaoliang, On Tue, 2 Jun 2020 at 08:25, Xiaoliang Yang <xiaoliang.yang_1@nxp.com> wrote: > > This series patches adds support for VCAP IS1 and ES0 module, each VCAP > correspond to a flow chain to offload. > > VCAP IS1 supports FLOW_ACTION_VLAN_MANGLE action to filter MAC, IP, > VLAN, protocol, and TCP/UDP ports keys and retag vlian tag, > FLOW_ACTION_PRIORITY action to classify packages to different Qos in hw. > > VCAP ES0 supports FLOW_ACTION_VLAN_PUSH action to filter vlan keys > and push a specific vlan tag to frames. > > Changes since v1->v2: > - Use different chain to assign rules to different hardware VCAP, and > use action goto chain to express flow order. > - Add FLOW_ACTION_PRIORITY to add Qos classification on VCAP IS1. > - Multiple actions support. > - Fix some code issues. > > Vladimir Oltean (3): > net: mscc: ocelot: introduce a new ocelot_target_{read,write} API > net: mscc: ocelot: generalize existing code for VCAP > net: dsa: tag_ocelot: use VLAN information from tagging header when > available > > Xiaoliang Yang (7): > net: mscc: ocelot: allocated rules to different hardware VCAP TCAMs by > chain index > net: mscc: ocelot: change vcap to be compatible with full and quad > entry > net: mscc: ocelot: VCAP IS1 support > net: mscc: ocelot: VCAP ES0 support > net: mscc: ocelot: multiple actions support > net: ocelot: return error if rule is not found > net: dsa: felix: correct VCAP IS2 keys offset > > drivers/net/dsa/ocelot/felix.c | 2 - > drivers/net/dsa/ocelot/felix.h | 2 - > drivers/net/dsa/ocelot/felix_vsc9959.c | 202 +++++- > drivers/net/ethernet/mscc/ocelot.c | 11 + > drivers/net/ethernet/mscc/ocelot_ace.c | 729 ++++++++++++++++------ > drivers/net/ethernet/mscc/ocelot_ace.h | 26 +- > drivers/net/ethernet/mscc/ocelot_board.c | 5 +- > drivers/net/ethernet/mscc/ocelot_flower.c | 95 ++- > drivers/net/ethernet/mscc/ocelot_io.c | 17 + > drivers/net/ethernet/mscc/ocelot_regs.c | 21 +- > drivers/net/ethernet/mscc/ocelot_s2.h | 64 -- > include/soc/mscc/ocelot.h | 39 +- > include/soc/mscc/ocelot_vcap.h | 199 +++++- > net/dsa/tag_ocelot.c | 29 + > 14 files changed, 1105 insertions(+), 336 deletions(-) > delete mode 100644 drivers/net/ethernet/mscc/ocelot_s2.h > > -- > 2.17.1 > First of all, net-next has just closed yesterday and will be closed for the following 2 weeks: http://vger.kernel.org/~davem/net-next.html Secondly, could you give an example of how different chains could express the fact that rules are executed in parallel between the IS1, IS2 and ES0 TCAMs? Thanks, -Vladimir
Hi Vladimir, On Tus, 2 Jun 2020 at 16:04, > First of all, net-next has just closed yesterday and will be closed for the following 2 weeks: > https://eur01.safelinks.protection.outlook.com/?url=http:%2F%2Fvger.kernel.org%2F~davem%2Fnet-next.html&data=02%7C01% 7Cxiaoliang.yang_1%40nxp.com%7C2fad4495dabc4f4ca5fd08d806cb70af%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637266818117666386&sdata=ziVybWb4HzYXanehF5KwNv5RJL%2BZz6NeFvrZWg657B8%3D&reserved=0 > > Secondly, could you give an example of how different chains could express the fact that rules are executed in parallel between the IS1, > IS2 and ES0 TCAMs? > Different TCAMs are not running in parallel, they have flow order: IS1->IS2->ES0. Using goto chain to express the flow order. For example: tc qdisc add dev swp0 ingress tc filter add dev swp0 chain 0 protocol 802.1Q parent ffff: flower skip_sw vlan_id 1 vlan_prio 1 action vlan modify id 2 priority 2 action goto chain 1 tc filter add dev swp0 chain 1 protocol 802.1Q parent ffff: flower skip_sw vlan_id 2 vlan_prio 2 action drop In this example, package with (vid=1,pcp=1) vlan tag will be modified to (vid=2,pcp=2) vlan tag on IS1, then will be dropped on IS2. If there is no rule match on IS1, it will still lookup on IS2. We can set a rule on chain 0 to express this: tc filter add dev swp0 chain 0 parent ffff: flower skip_sw action goto chain 1 In addition, VSC9959 chip has PSFP and "Sequence Generation recovery" modules are running after IS2, the flow order like this: IS1->IS2->PSFP-> "Sequence Generation recovery" ->ES0, we can also add chains like this to express these two modules in future. BTW, where should I sent patches to due to net-next closed? Thanks, Xiaoliang Yang
Hi Xiaoliang, On Tue, 2 Jun 2020 at 11:50, Xiaoliang Yang <xiaoliang.yang_1@nxp.com> wrote: > > Hi Vladimir, > > On Tus, 2 Jun 2020 at 16:04, > > First of all, net-next has just closed yesterday and will be closed for the following 2 weeks: > > https://eur01.safelinks.protection.outlook.com/?url=http:%2F%2Fvger.kernel.org%2F~davem%2Fnet-next.html&data=02%7C01% 7Cxiaoliang.yang_1%40nxp.com%7C2fad4495dabc4f4ca5fd08d806cb70af%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637266818117666386&sdata=ziVybWb4HzYXanehF5KwNv5RJL%2BZz6NeFvrZWg657B8%3D&reserved=0 > > > > Secondly, could you give an example of how different chains could express the fact that rules are executed in parallel between the IS1, > > IS2 and ES0 TCAMs? > > > > Different TCAMs are not running in parallel, they have flow order: IS1->IS2->ES0. Using goto chain to express the flow order. > For example: > tc qdisc add dev swp0 ingress > tc filter add dev swp0 chain 0 protocol 802.1Q parent ffff: flower skip_sw vlan_id 1 vlan_prio 1 action vlan modify id 2 priority 2 action goto chain 1 > tc filter add dev swp0 chain 1 protocol 802.1Q parent ffff: flower skip_sw vlan_id 2 vlan_prio 2 action drop > In this example, package with (vid=1,pcp=1) vlan tag will be modified to (vid=2,pcp=2) vlan tag on IS1, then will be dropped on IS2. > > If there is no rule match on IS1, it will still lookup on IS2. We can set a rule on chain 0 to express this: > tc filter add dev swp0 chain 0 parent ffff: flower skip_sw action goto chain 1 > > In addition, VSC9959 chip has PSFP and "Sequence Generation recovery" modules are running after IS2, the flow order like this: IS1->IS2->PSFP-> "Sequence Generation recovery" ->ES0, we can also add chains like this to express these two modules in future. > I've been pondering over what is a good abstraction for 802.1CB and I don't think that it would be a tc action. After reading Annex C "Frame Replication and Elimination for Reliability in systems" in 8021CB-2017, I think maybe it should be modeled as a stacked net device a la hsr, but with the ability to add its own stream filtering rules and actions (a la bridge fdb). But for the PSFP policers, in principle I think you are correct, we could designate a static chain id for those. > BTW, where should I sent patches to due to net-next closed? > You can keep sending patches just as you did. There's nothing wrong with doing that as long as you're only doing it for the feedback (RFC == Request For Comments). Since David receives a lot of patches and the backlog builds up very quickly, he just rejects patches sent to net-next during the merge window instead of queuing them up. Patches that are bugfixes (not the case here, just in general) can be sent to the net tree at all times (even during the merge window). In all cases, the mailing list is the same, just the --subject-prefix is different (net, net-next, rfc). > Thanks, > Xiaoliang Yang Thanks, -Vladimir
This series patches adds support for VCAP IS1 and ES0 module, each VCAP correspond to a flow chain to offload. VCAP IS1 supports FLOW_ACTION_VLAN_MANGLE action to filter MAC, IP, VLAN, protocol, and TCP/UDP ports keys and retag vlian tag, FLOW_ACTION_PRIORITY action to classify packages to different Qos in hw. VCAP ES0 supports FLOW_ACTION_VLAN_PUSH action to filter vlan keys and push a specific vlan tag to frames. Changes since v1->v2: - Use different chain to assign rules to different hardware VCAP, and use action goto chain to express flow order. - Add FLOW_ACTION_PRIORITY to add Qos classification on VCAP IS1. - Multiple actions support. - Fix some code issues. Vladimir Oltean (3): net: mscc: ocelot: introduce a new ocelot_target_{read,write} API net: mscc: ocelot: generalize existing code for VCAP net: dsa: tag_ocelot: use VLAN information from tagging header when available Xiaoliang Yang (7): net: mscc: ocelot: allocated rules to different hardware VCAP TCAMs by chain index net: mscc: ocelot: change vcap to be compatible with full and quad entry net: mscc: ocelot: VCAP IS1 support net: mscc: ocelot: VCAP ES0 support net: mscc: ocelot: multiple actions support net: ocelot: return error if rule is not found net: dsa: felix: correct VCAP IS2 keys offset drivers/net/dsa/ocelot/felix.c | 2 - drivers/net/dsa/ocelot/felix.h | 2 - drivers/net/dsa/ocelot/felix_vsc9959.c | 202 +++++- drivers/net/ethernet/mscc/ocelot.c | 11 + drivers/net/ethernet/mscc/ocelot_ace.c | 729 ++++++++++++++++------ drivers/net/ethernet/mscc/ocelot_ace.h | 26 +- drivers/net/ethernet/mscc/ocelot_board.c | 5 +- drivers/net/ethernet/mscc/ocelot_flower.c | 95 ++- drivers/net/ethernet/mscc/ocelot_io.c | 17 + drivers/net/ethernet/mscc/ocelot_regs.c | 21 +- drivers/net/ethernet/mscc/ocelot_s2.h | 64 -- include/soc/mscc/ocelot.h | 39 +- include/soc/mscc/ocelot_vcap.h | 199 +++++- net/dsa/tag_ocelot.c | 29 + 14 files changed, 1105 insertions(+), 336 deletions(-) delete mode 100644 drivers/net/ethernet/mscc/ocelot_s2.h