2018-07-14 19:29:24 +08:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 */
|
2018-05-31 16:07:43 +08:00
|
|
|
/*
|
|
|
|
* RSS and Classifier definitions for Marvell PPv2 Network Controller
|
|
|
|
*
|
|
|
|
* Copyright (C) 2014 Marvell
|
|
|
|
*
|
|
|
|
* Marcin Wojtas <mw@semihalf.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef _MVPP2_CLS_H_
|
|
|
|
#define _MVPP2_CLS_H_
|
|
|
|
|
2018-07-12 19:54:11 +08:00
|
|
|
#include "mvpp2.h"
|
net: mvpp2: use classifier to assign default rx queue
The PPv2 Controller has a classifier, that can perform multiple lookup
operations for each packet, using different engines.
One of these engines is the C2 engine, which performs TCAM based lookups
on data extracted from the packet header. When a packet matches an
entry, the engine sets various attributes, used to perform
classification operations.
One of these attributes is the rx queue in which the packet should be sent.
The current code uses the lookup_id table (also called decoding table)
to assign the rx queue. However, this only works if we use one entry per
port in the decoding table, which won't be the case once we add RSS
lookups.
This patch uses the C2 engine to assign the rx queue to each packet.
The C2 engine is used through the flow table, which dictates what
classification operations are done for a given flow.
Right now, we have one flow per port, which contains every ingress
packet for this port.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-12 19:54:24 +08:00
|
|
|
#include "mvpp2_prs.h"
|
2018-07-12 19:54:11 +08:00
|
|
|
|
2018-05-31 16:07:43 +08:00
|
|
|
/* Classifier constants */
|
|
|
|
#define MVPP2_CLS_FLOWS_TBL_SIZE 512
|
|
|
|
#define MVPP2_CLS_FLOWS_TBL_DATA_WORDS 3
|
|
|
|
#define MVPP2_CLS_LKP_TBL_SIZE 64
|
|
|
|
#define MVPP2_CLS_RX_QUEUES 256
|
|
|
|
|
net: mvpp2: use classifier to assign default rx queue
The PPv2 Controller has a classifier, that can perform multiple lookup
operations for each packet, using different engines.
One of these engines is the C2 engine, which performs TCAM based lookups
on data extracted from the packet header. When a packet matches an
entry, the engine sets various attributes, used to perform
classification operations.
One of these attributes is the rx queue in which the packet should be sent.
The current code uses the lookup_id table (also called decoding table)
to assign the rx queue. However, this only works if we use one entry per
port in the decoding table, which won't be the case once we add RSS
lookups.
This patch uses the C2 engine to assign the rx queue to each packet.
The C2 engine is used through the flow table, which dictates what
classification operations are done for a given flow.
Right now, we have one flow per port, which contains every ingress
packet for this port.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-12 19:54:24 +08:00
|
|
|
/* Classifier flow constants */
|
net: mvpp2: split ingress traffic into multiple flows
The PPv2 classifier allows to perform classification operations on each
ingress packet, based on the flow the packet is assigned to.
The current code uses only 1 flow per port, and the only classification
action consists of assigning the rx queue to the packet, depending on the
port.
In preparation for adding RSS support, we have to split all incoming
traffic into different flows. Since RSS assigns a rx queue depending on
the hash of some header fields, we have to make sure that the hash is
generated in a consistent way for all packets in the same flow.
What we call a "flow" is actually a set of attributes attached to a
packet that depends on various L2/L3/L4 info.
This patch introduces 52 flows, wich are a combination of various L2, L3
and L4 attributes :
- Whether or not the packet has a VLAN tag
- Whether the packet is IPv4, IPv6 or something else
- Whether the packet is TCP, UDP or something else
- Whether or not the packet is fragmented at L3 level.
The flow is associated to a packet by the Header Parser. Each flow
corresponds to an entry in the decoding table. This entry then points to
the sequence of classification lookups to be performed by the
classifier, represented in the flow table.
For now, the only lookup we perform is a C2 lookup to set the default
rx queue.
Header parser Dec table
Ingress pkt +-------------+ flow id +----------------------------+
------------->| TCAM + SRAM |-------->|TCP IPv4 w/ VLAN, not frag |
+-------------+ |TCP IPv4 w/o VLAN, not frag |
|TCP IPv4 w/ VLAN, frag |--+
|etc. | |
+----------------------------+ |
|
Flow table |
+------------+ +---------------------+ |
To RxQ <---| Classifier |<-------| flow 0: C2 lookup |<--------+
+------------+ | flow 1: C2 lookup |
| | ... |
+------------+ | flow 51 : C2 lookup |
| C2 engine | +---------------------+
+------------+
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-12 19:54:25 +08:00
|
|
|
|
|
|
|
#define MVPP2_FLOW_N_FIELDS 4
|
|
|
|
|
net: mvpp2: use classifier to assign default rx queue
The PPv2 Controller has a classifier, that can perform multiple lookup
operations for each packet, using different engines.
One of these engines is the C2 engine, which performs TCAM based lookups
on data extracted from the packet header. When a packet matches an
entry, the engine sets various attributes, used to perform
classification operations.
One of these attributes is the rx queue in which the packet should be sent.
The current code uses the lookup_id table (also called decoding table)
to assign the rx queue. However, this only works if we use one entry per
port in the decoding table, which won't be the case once we add RSS
lookups.
This patch uses the C2 engine to assign the rx queue to each packet.
The C2 engine is used through the flow table, which dictates what
classification operations are done for a given flow.
Right now, we have one flow per port, which contains every ingress
packet for this port.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-12 19:54:24 +08:00
|
|
|
enum mvpp2_cls_engine {
|
|
|
|
MVPP22_CLS_ENGINE_C2 = 1,
|
|
|
|
MVPP22_CLS_ENGINE_C3A,
|
|
|
|
MVPP22_CLS_ENGINE_C3B,
|
|
|
|
MVPP22_CLS_ENGINE_C4,
|
|
|
|
MVPP22_CLS_ENGINE_C3HA = 6,
|
|
|
|
MVPP22_CLS_ENGINE_C3HB = 7,
|
|
|
|
};
|
|
|
|
|
net: mvpp2: split ingress traffic into multiple flows
The PPv2 classifier allows to perform classification operations on each
ingress packet, based on the flow the packet is assigned to.
The current code uses only 1 flow per port, and the only classification
action consists of assigning the rx queue to the packet, depending on the
port.
In preparation for adding RSS support, we have to split all incoming
traffic into different flows. Since RSS assigns a rx queue depending on
the hash of some header fields, we have to make sure that the hash is
generated in a consistent way for all packets in the same flow.
What we call a "flow" is actually a set of attributes attached to a
packet that depends on various L2/L3/L4 info.
This patch introduces 52 flows, wich are a combination of various L2, L3
and L4 attributes :
- Whether or not the packet has a VLAN tag
- Whether the packet is IPv4, IPv6 or something else
- Whether the packet is TCP, UDP or something else
- Whether or not the packet is fragmented at L3 level.
The flow is associated to a packet by the Header Parser. Each flow
corresponds to an entry in the decoding table. This entry then points to
the sequence of classification lookups to be performed by the
classifier, represented in the flow table.
For now, the only lookup we perform is a C2 lookup to set the default
rx queue.
Header parser Dec table
Ingress pkt +-------------+ flow id +----------------------------+
------------->| TCAM + SRAM |-------->|TCP IPv4 w/ VLAN, not frag |
+-------------+ |TCP IPv4 w/o VLAN, not frag |
|TCP IPv4 w/ VLAN, frag |--+
|etc. | |
+----------------------------+ |
|
Flow table |
+------------+ +---------------------+ |
To RxQ <---| Classifier |<-------| flow 0: C2 lookup |<--------+
+------------+ | flow 1: C2 lookup |
| | ... |
+------------+ | flow 51 : C2 lookup |
| C2 engine | +---------------------+
+------------+
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-12 19:54:25 +08:00
|
|
|
#define MVPP22_CLS_HEK_OPT_MAC_DA BIT(0)
|
|
|
|
#define MVPP22_CLS_HEK_OPT_VLAN BIT(1)
|
|
|
|
#define MVPP22_CLS_HEK_OPT_L3_PROTO BIT(2)
|
|
|
|
#define MVPP22_CLS_HEK_OPT_IP4SA BIT(3)
|
|
|
|
#define MVPP22_CLS_HEK_OPT_IP4DA BIT(4)
|
|
|
|
#define MVPP22_CLS_HEK_OPT_IP6SA BIT(5)
|
|
|
|
#define MVPP22_CLS_HEK_OPT_IP6DA BIT(6)
|
|
|
|
#define MVPP22_CLS_HEK_OPT_L4SIP BIT(7)
|
|
|
|
#define MVPP22_CLS_HEK_OPT_L4DIP BIT(8)
|
|
|
|
#define MVPP22_CLS_HEK_N_FIELDS 9
|
|
|
|
|
|
|
|
#define MVPP22_CLS_HEK_L4_OPTS (MVPP22_CLS_HEK_OPT_L4SIP | \
|
|
|
|
MVPP22_CLS_HEK_OPT_L4DIP)
|
|
|
|
|
|
|
|
#define MVPP22_CLS_HEK_IP4_2T (MVPP22_CLS_HEK_OPT_IP4SA | \
|
|
|
|
MVPP22_CLS_HEK_OPT_IP4DA)
|
|
|
|
|
|
|
|
#define MVPP22_CLS_HEK_IP6_2T (MVPP22_CLS_HEK_OPT_IP6SA | \
|
|
|
|
MVPP22_CLS_HEK_OPT_IP6DA)
|
|
|
|
|
|
|
|
/* The fifth tuple in "5T" is the L4_Info field */
|
|
|
|
#define MVPP22_CLS_HEK_IP4_5T (MVPP22_CLS_HEK_IP4_2T | \
|
|
|
|
MVPP22_CLS_HEK_L4_OPTS)
|
|
|
|
|
|
|
|
#define MVPP22_CLS_HEK_IP6_5T (MVPP22_CLS_HEK_IP6_2T | \
|
|
|
|
MVPP22_CLS_HEK_L4_OPTS)
|
|
|
|
|
2018-07-12 19:54:26 +08:00
|
|
|
enum mvpp2_cls_field_id {
|
|
|
|
MVPP22_CLS_FIELD_MAC_DA = 0x03,
|
|
|
|
MVPP22_CLS_FIELD_VLAN = 0x06,
|
|
|
|
MVPP22_CLS_FIELD_L3_PROTO = 0x0f,
|
|
|
|
MVPP22_CLS_FIELD_IP4SA = 0x10,
|
|
|
|
MVPP22_CLS_FIELD_IP4DA = 0x11,
|
|
|
|
MVPP22_CLS_FIELD_IP6SA = 0x17,
|
|
|
|
MVPP22_CLS_FIELD_IP6DA = 0x1a,
|
|
|
|
MVPP22_CLS_FIELD_L4SIP = 0x1d,
|
|
|
|
MVPP22_CLS_FIELD_L4DIP = 0x1e,
|
|
|
|
};
|
|
|
|
|
net: mvpp2: use classifier to assign default rx queue
The PPv2 Controller has a classifier, that can perform multiple lookup
operations for each packet, using different engines.
One of these engines is the C2 engine, which performs TCAM based lookups
on data extracted from the packet header. When a packet matches an
entry, the engine sets various attributes, used to perform
classification operations.
One of these attributes is the rx queue in which the packet should be sent.
The current code uses the lookup_id table (also called decoding table)
to assign the rx queue. However, this only works if we use one entry per
port in the decoding table, which won't be the case once we add RSS
lookups.
This patch uses the C2 engine to assign the rx queue to each packet.
The C2 engine is used through the flow table, which dictates what
classification operations are done for a given flow.
Right now, we have one flow per port, which contains every ingress
packet for this port.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-12 19:54:24 +08:00
|
|
|
enum mvpp2_cls_flow_seq {
|
|
|
|
MVPP2_CLS_FLOW_SEQ_NORMAL = 0,
|
|
|
|
MVPP2_CLS_FLOW_SEQ_FIRST1,
|
|
|
|
MVPP2_CLS_FLOW_SEQ_FIRST2,
|
|
|
|
MVPP2_CLS_FLOW_SEQ_LAST,
|
|
|
|
MVPP2_CLS_FLOW_SEQ_MIDDLE
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Classifier C2 engine constants */
|
|
|
|
#define MVPP22_CLS_C2_TCAM_EN(data) ((data) << 16)
|
|
|
|
|
|
|
|
enum mvpp22_cls_c2_action {
|
|
|
|
MVPP22_C2_NO_UPD = 0,
|
|
|
|
MVPP22_C2_NO_UPD_LOCK,
|
|
|
|
MVPP22_C2_UPD,
|
|
|
|
MVPP22_C2_UPD_LOCK,
|
|
|
|
};
|
|
|
|
|
|
|
|
enum mvpp22_cls_c2_fwd_action {
|
|
|
|
MVPP22_C2_FWD_NO_UPD = 0,
|
|
|
|
MVPP22_C2_FWD_NO_UPD_LOCK,
|
|
|
|
MVPP22_C2_FWD_SW,
|
|
|
|
MVPP22_C2_FWD_SW_LOCK,
|
|
|
|
MVPP22_C2_FWD_HW,
|
|
|
|
MVPP22_C2_FWD_HW_LOCK,
|
|
|
|
MVPP22_C2_FWD_HW_LOW_LAT,
|
|
|
|
MVPP22_C2_FWD_HW_LOW_LAT_LOCK,
|
|
|
|
};
|
|
|
|
|
|
|
|
#define MVPP2_CLS_C2_TCAM_WORDS 5
|
|
|
|
#define MVPP2_CLS_C2_ATTR_WORDS 5
|
|
|
|
|
|
|
|
struct mvpp2_cls_c2_entry {
|
|
|
|
u32 index;
|
|
|
|
u32 tcam[MVPP2_CLS_C2_TCAM_WORDS];
|
|
|
|
u32 act;
|
|
|
|
u32 attr[MVPP2_CLS_C2_ATTR_WORDS];
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Classifier C2 engine entries */
|
|
|
|
#define MVPP22_CLS_C2_RSS_ENTRY(port) (port)
|
|
|
|
#define MVPP22_CLS_C2_N_ENTRIES MVPP2_MAX_PORTS
|
|
|
|
|
net: mvpp2: split ingress traffic into multiple flows
The PPv2 classifier allows to perform classification operations on each
ingress packet, based on the flow the packet is assigned to.
The current code uses only 1 flow per port, and the only classification
action consists of assigning the rx queue to the packet, depending on the
port.
In preparation for adding RSS support, we have to split all incoming
traffic into different flows. Since RSS assigns a rx queue depending on
the hash of some header fields, we have to make sure that the hash is
generated in a consistent way for all packets in the same flow.
What we call a "flow" is actually a set of attributes attached to a
packet that depends on various L2/L3/L4 info.
This patch introduces 52 flows, wich are a combination of various L2, L3
and L4 attributes :
- Whether or not the packet has a VLAN tag
- Whether the packet is IPv4, IPv6 or something else
- Whether the packet is TCP, UDP or something else
- Whether or not the packet is fragmented at L3 level.
The flow is associated to a packet by the Header Parser. Each flow
corresponds to an entry in the decoding table. This entry then points to
the sequence of classification lookups to be performed by the
classifier, represented in the flow table.
For now, the only lookup we perform is a C2 lookup to set the default
rx queue.
Header parser Dec table
Ingress pkt +-------------+ flow id +----------------------------+
------------->| TCAM + SRAM |-------->|TCP IPv4 w/ VLAN, not frag |
+-------------+ |TCP IPv4 w/o VLAN, not frag |
|TCP IPv4 w/ VLAN, frag |--+
|etc. | |
+----------------------------+ |
|
Flow table |
+------------+ +---------------------+ |
To RxQ <---| Classifier |<-------| flow 0: C2 lookup |<--------+
+------------+ | flow 1: C2 lookup |
| | ... |
+------------+ | flow 51 : C2 lookup |
| C2 engine | +---------------------+
+------------+
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-12 19:54:25 +08:00
|
|
|
/* RSS flow entries in the flow table. We have 2 entries per port for RSS.
|
|
|
|
*
|
|
|
|
* The first performs a lookup using the C2 TCAM engine, to tag the
|
|
|
|
* packet for software forwarding (needed for RSS), enable or disable RSS, and
|
|
|
|
* assign the default rx queue.
|
|
|
|
*
|
|
|
|
* The second configures the hash generation, by specifying which fields of the
|
|
|
|
* packet header are used to generate the hash, and specifies the relevant hash
|
|
|
|
* engine to use.
|
|
|
|
*/
|
net: mvpp2: use classifier to assign default rx queue
The PPv2 Controller has a classifier, that can perform multiple lookup
operations for each packet, using different engines.
One of these engines is the C2 engine, which performs TCAM based lookups
on data extracted from the packet header. When a packet matches an
entry, the engine sets various attributes, used to perform
classification operations.
One of these attributes is the rx queue in which the packet should be sent.
The current code uses the lookup_id table (also called decoding table)
to assign the rx queue. However, this only works if we use one entry per
port in the decoding table, which won't be the case once we add RSS
lookups.
This patch uses the C2 engine to assign the rx queue to each packet.
The C2 engine is used through the flow table, which dictates what
classification operations are done for a given flow.
Right now, we have one flow per port, which contains every ingress
packet for this port.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-12 19:54:24 +08:00
|
|
|
#define MVPP22_RSS_FLOW_C2_OFFS 0
|
net: mvpp2: split ingress traffic into multiple flows
The PPv2 classifier allows to perform classification operations on each
ingress packet, based on the flow the packet is assigned to.
The current code uses only 1 flow per port, and the only classification
action consists of assigning the rx queue to the packet, depending on the
port.
In preparation for adding RSS support, we have to split all incoming
traffic into different flows. Since RSS assigns a rx queue depending on
the hash of some header fields, we have to make sure that the hash is
generated in a consistent way for all packets in the same flow.
What we call a "flow" is actually a set of attributes attached to a
packet that depends on various L2/L3/L4 info.
This patch introduces 52 flows, wich are a combination of various L2, L3
and L4 attributes :
- Whether or not the packet has a VLAN tag
- Whether the packet is IPv4, IPv6 or something else
- Whether the packet is TCP, UDP or something else
- Whether or not the packet is fragmented at L3 level.
The flow is associated to a packet by the Header Parser. Each flow
corresponds to an entry in the decoding table. This entry then points to
the sequence of classification lookups to be performed by the
classifier, represented in the flow table.
For now, the only lookup we perform is a C2 lookup to set the default
rx queue.
Header parser Dec table
Ingress pkt +-------------+ flow id +----------------------------+
------------->| TCAM + SRAM |-------->|TCP IPv4 w/ VLAN, not frag |
+-------------+ |TCP IPv4 w/o VLAN, not frag |
|TCP IPv4 w/ VLAN, frag |--+
|etc. | |
+----------------------------+ |
|
Flow table |
+------------+ +---------------------+ |
To RxQ <---| Classifier |<-------| flow 0: C2 lookup |<--------+
+------------+ | flow 1: C2 lookup |
| | ... |
+------------+ | flow 51 : C2 lookup |
| C2 engine | +---------------------+
+------------+
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-12 19:54:25 +08:00
|
|
|
#define MVPP22_RSS_FLOW_HASH_OFFS 1
|
|
|
|
#define MVPP22_RSS_FLOW_SIZE (MVPP22_RSS_FLOW_HASH_OFFS + 1)
|
|
|
|
|
|
|
|
#define MVPP22_RSS_FLOW_C2(port) ((port) * MVPP22_RSS_FLOW_SIZE + \
|
|
|
|
MVPP22_RSS_FLOW_C2_OFFS)
|
|
|
|
#define MVPP22_RSS_FLOW_HASH(port) ((port) * MVPP22_RSS_FLOW_SIZE + \
|
|
|
|
MVPP22_RSS_FLOW_HASH_OFFS)
|
|
|
|
#define MVPP22_RSS_FLOW_FIRST(port) MVPP22_RSS_FLOW_C2(port)
|
|
|
|
|
|
|
|
/* Packet flow ID */
|
|
|
|
enum mvpp2_prs_flow {
|
|
|
|
MVPP2_FL_START = 8,
|
|
|
|
MVPP2_FL_IP4_TCP_NF_UNTAG = MVPP2_FL_START,
|
|
|
|
MVPP2_FL_IP4_UDP_NF_UNTAG,
|
|
|
|
MVPP2_FL_IP4_TCP_NF_TAG,
|
|
|
|
MVPP2_FL_IP4_UDP_NF_TAG,
|
|
|
|
MVPP2_FL_IP6_TCP_NF_UNTAG,
|
|
|
|
MVPP2_FL_IP6_UDP_NF_UNTAG,
|
|
|
|
MVPP2_FL_IP6_TCP_NF_TAG,
|
|
|
|
MVPP2_FL_IP6_UDP_NF_TAG,
|
|
|
|
MVPP2_FL_IP4_TCP_FRAG_UNTAG,
|
|
|
|
MVPP2_FL_IP4_UDP_FRAG_UNTAG,
|
|
|
|
MVPP2_FL_IP4_TCP_FRAG_TAG,
|
|
|
|
MVPP2_FL_IP4_UDP_FRAG_TAG,
|
|
|
|
MVPP2_FL_IP6_TCP_FRAG_UNTAG,
|
|
|
|
MVPP2_FL_IP6_UDP_FRAG_UNTAG,
|
|
|
|
MVPP2_FL_IP6_TCP_FRAG_TAG,
|
|
|
|
MVPP2_FL_IP6_UDP_FRAG_TAG,
|
|
|
|
MVPP2_FL_IP4_UNTAG, /* non-TCP, non-UDP, same for below */
|
|
|
|
MVPP2_FL_IP4_TAG,
|
|
|
|
MVPP2_FL_IP6_UNTAG,
|
|
|
|
MVPP2_FL_IP6_TAG,
|
|
|
|
MVPP2_FL_NON_IP_UNTAG,
|
|
|
|
MVPP2_FL_NON_IP_TAG,
|
|
|
|
MVPP2_FL_LAST,
|
|
|
|
};
|
|
|
|
|
2019-03-27 16:44:08 +08:00
|
|
|
enum mvpp2_cls_lu_type {
|
|
|
|
MVPP2_CLS_LU_ALL = 0,
|
|
|
|
};
|
|
|
|
|
|
|
|
/* LU Type defined for all engines, and specified in the flow table */
|
|
|
|
#define MVPP2_CLS_LU_TYPE_MASK 0x3f
|
|
|
|
|
2019-03-27 16:44:09 +08:00
|
|
|
#define MVPP2_N_FLOWS (MVPP2_FL_LAST - MVPP2_FL_START)
|
|
|
|
|
net: mvpp2: split ingress traffic into multiple flows
The PPv2 classifier allows to perform classification operations on each
ingress packet, based on the flow the packet is assigned to.
The current code uses only 1 flow per port, and the only classification
action consists of assigning the rx queue to the packet, depending on the
port.
In preparation for adding RSS support, we have to split all incoming
traffic into different flows. Since RSS assigns a rx queue depending on
the hash of some header fields, we have to make sure that the hash is
generated in a consistent way for all packets in the same flow.
What we call a "flow" is actually a set of attributes attached to a
packet that depends on various L2/L3/L4 info.
This patch introduces 52 flows, wich are a combination of various L2, L3
and L4 attributes :
- Whether or not the packet has a VLAN tag
- Whether the packet is IPv4, IPv6 or something else
- Whether the packet is TCP, UDP or something else
- Whether or not the packet is fragmented at L3 level.
The flow is associated to a packet by the Header Parser. Each flow
corresponds to an entry in the decoding table. This entry then points to
the sequence of classification lookups to be performed by the
classifier, represented in the flow table.
For now, the only lookup we perform is a C2 lookup to set the default
rx queue.
Header parser Dec table
Ingress pkt +-------------+ flow id +----------------------------+
------------->| TCAM + SRAM |-------->|TCP IPv4 w/ VLAN, not frag |
+-------------+ |TCP IPv4 w/o VLAN, not frag |
|TCP IPv4 w/ VLAN, frag |--+
|etc. | |
+----------------------------+ |
|
Flow table |
+------------+ +---------------------+ |
To RxQ <---| Classifier |<-------| flow 0: C2 lookup |<--------+
+------------+ | flow 1: C2 lookup |
| | ... |
+------------+ | flow 51 : C2 lookup |
| C2 engine | +---------------------+
+------------+
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-12 19:54:25 +08:00
|
|
|
struct mvpp2_cls_flow {
|
|
|
|
/* The L2-L4 traffic flow type */
|
|
|
|
int flow_type;
|
|
|
|
|
|
|
|
/* The first id in the flow table for this flow */
|
|
|
|
u16 flow_id;
|
|
|
|
|
|
|
|
/* The supported HEK fields for this flow */
|
|
|
|
u16 supported_hash_opts;
|
|
|
|
|
|
|
|
/* The Header Parser result_info that matches this flow */
|
|
|
|
struct mvpp2_prs_result_info prs_ri;
|
|
|
|
};
|
|
|
|
|
net: mvpp2: use classifier to assign default rx queue
The PPv2 Controller has a classifier, that can perform multiple lookup
operations for each packet, using different engines.
One of these engines is the C2 engine, which performs TCAM based lookups
on data extracted from the packet header. When a packet matches an
entry, the engine sets various attributes, used to perform
classification operations.
One of these attributes is the rx queue in which the packet should be sent.
The current code uses the lookup_id table (also called decoding table)
to assign the rx queue. However, this only works if we use one entry per
port in the decoding table, which won't be the case once we add RSS
lookups.
This patch uses the C2 engine to assign the rx queue to each packet.
The C2 engine is used through the flow table, which dictates what
classification operations are done for a given flow.
Right now, we have one flow per port, which contains every ingress
packet for this port.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-12 19:54:24 +08:00
|
|
|
|
net: mvpp2: split ingress traffic into multiple flows
The PPv2 classifier allows to perform classification operations on each
ingress packet, based on the flow the packet is assigned to.
The current code uses only 1 flow per port, and the only classification
action consists of assigning the rx queue to the packet, depending on the
port.
In preparation for adding RSS support, we have to split all incoming
traffic into different flows. Since RSS assigns a rx queue depending on
the hash of some header fields, we have to make sure that the hash is
generated in a consistent way for all packets in the same flow.
What we call a "flow" is actually a set of attributes attached to a
packet that depends on various L2/L3/L4 info.
This patch introduces 52 flows, wich are a combination of various L2, L3
and L4 attributes :
- Whether or not the packet has a VLAN tag
- Whether the packet is IPv4, IPv6 or something else
- Whether the packet is TCP, UDP or something else
- Whether or not the packet is fragmented at L3 level.
The flow is associated to a packet by the Header Parser. Each flow
corresponds to an entry in the decoding table. This entry then points to
the sequence of classification lookups to be performed by the
classifier, represented in the flow table.
For now, the only lookup we perform is a C2 lookup to set the default
rx queue.
Header parser Dec table
Ingress pkt +-------------+ flow id +----------------------------+
------------->| TCAM + SRAM |-------->|TCP IPv4 w/ VLAN, not frag |
+-------------+ |TCP IPv4 w/o VLAN, not frag |
|TCP IPv4 w/ VLAN, frag |--+
|etc. | |
+----------------------------+ |
|
Flow table |
+------------+ +---------------------+ |
To RxQ <---| Classifier |<-------| flow 0: C2 lookup |<--------+
+------------+ | flow 1: C2 lookup |
| | ... |
+------------+ | flow 51 : C2 lookup |
| C2 engine | +---------------------+
+------------+
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-12 19:54:25 +08:00
|
|
|
#define MVPP2_ENTRIES_PER_FLOW (MVPP2_MAX_PORTS + 1)
|
2019-03-27 16:44:07 +08:00
|
|
|
#define MVPP2_FLOW_C2_ENTRY(id) ((((id) - MVPP2_FL_START) * \
|
|
|
|
MVPP2_ENTRIES_PER_FLOW) + 1)
|
|
|
|
#define MVPP2_PORT_FLOW_HASH_ENTRY(port, id) (MVPP2_FLOW_C2_ENTRY(id) + \
|
|
|
|
1 + (port))
|
|
|
|
|
2018-05-31 16:07:43 +08:00
|
|
|
struct mvpp2_cls_flow_entry {
|
|
|
|
u32 index;
|
|
|
|
u32 data[MVPP2_CLS_FLOWS_TBL_DATA_WORDS];
|
|
|
|
};
|
|
|
|
|
|
|
|
struct mvpp2_cls_lookup_entry {
|
|
|
|
u32 lkpid;
|
|
|
|
u32 way;
|
|
|
|
u32 data;
|
|
|
|
};
|
|
|
|
|
2018-07-12 19:54:20 +08:00
|
|
|
void mvpp22_rss_fill_table(struct mvpp2_port *port, u32 table);
|
|
|
|
|
2018-07-12 19:54:23 +08:00
|
|
|
void mvpp22_rss_port_init(struct mvpp2_port *port);
|
2018-05-31 16:07:43 +08:00
|
|
|
|
2018-07-12 19:54:26 +08:00
|
|
|
void mvpp22_rss_enable(struct mvpp2_port *port);
|
|
|
|
void mvpp22_rss_disable(struct mvpp2_port *port);
|
|
|
|
|
2018-07-12 19:54:27 +08:00
|
|
|
int mvpp2_ethtool_rxfh_get(struct mvpp2_port *port, struct ethtool_rxnfc *info);
|
|
|
|
int mvpp2_ethtool_rxfh_set(struct mvpp2_port *port, struct ethtool_rxnfc *info);
|
|
|
|
|
2018-05-31 16:07:43 +08:00
|
|
|
void mvpp2_cls_init(struct mvpp2 *priv);
|
|
|
|
|
|
|
|
void mvpp2_cls_port_config(struct mvpp2_port *port);
|
|
|
|
|
|
|
|
void mvpp2_cls_oversize_rxq_set(struct mvpp2_port *port);
|
|
|
|
|
2018-07-14 19:29:27 +08:00
|
|
|
int mvpp2_cls_flow_eng_get(struct mvpp2_cls_flow_entry *fe);
|
|
|
|
|
|
|
|
u16 mvpp2_flow_get_hek_fields(struct mvpp2_cls_flow_entry *fe);
|
|
|
|
|
|
|
|
struct mvpp2_cls_flow *mvpp2_cls_flow_get(int flow);
|
|
|
|
|
2018-07-14 19:29:28 +08:00
|
|
|
u32 mvpp2_cls_flow_hits(struct mvpp2 *priv, int index);
|
|
|
|
|
2018-07-14 19:29:27 +08:00
|
|
|
void mvpp2_cls_flow_read(struct mvpp2 *priv, int index,
|
|
|
|
struct mvpp2_cls_flow_entry *fe);
|
|
|
|
|
2018-07-14 19:29:28 +08:00
|
|
|
u32 mvpp2_cls_lookup_hits(struct mvpp2 *priv, int index);
|
|
|
|
|
2018-07-14 19:29:27 +08:00
|
|
|
void mvpp2_cls_lookup_read(struct mvpp2 *priv, int lkpid, int way,
|
|
|
|
struct mvpp2_cls_lookup_entry *le);
|
|
|
|
|
2018-07-14 19:29:28 +08:00
|
|
|
u32 mvpp2_cls_c2_hit_count(struct mvpp2 *priv, int c2_index);
|
|
|
|
|
2018-07-14 19:29:27 +08:00
|
|
|
void mvpp2_cls_c2_read(struct mvpp2 *priv, int index,
|
|
|
|
struct mvpp2_cls_c2_entry *c2);
|
|
|
|
|
2018-05-31 16:07:43 +08:00
|
|
|
#endif
|