Re: [PATCH v3 net-next 01/13] octeontx2-af: Modify default KEX profile to extract TX packet fields
From: Naveen Mamindlapalli <hidden>
Date: 2020-11-14 18:34:06
Also in:
lkml
Hi Alexander, Thanks for the review.
-----Original Message----- From: Alexander Duyck <redacted> Sent: Friday, November 13, 2020 1:32 AM To: Naveen Mamindlapalli <redacted> Cc: Netdev <redacted>; LKML <redacted>; Jakub Kicinski [off-list ref]; David Miller [off-list ref]; saeed@kernel.org; Sunil Kovvuri Goutham [off-list ref]; Linu Cherian [off-list ref]; Geethasowjanya Akula [off-list ref]; Jerin Jacob Kollanukkaran [off-list ref]; Subbaraya Sundeep Bhatta [off-list ref]; Hariprasad Kelam [off-list ref] Subject: Re: [PATCH v3 net-next 01/13] octeontx2-af: Modify default KEX profile to extract TX packet fields On Tue, Nov 10, 2020 at 11:22 PM Naveen Mamindlapalli [off-list ref] wrote:quoted
From: Stanislaw Kardach <redacted> The current default Key Extraction(KEX) profile can only use RX packet fields while generating the MCAM search key. The profile can't be used for matching TX packet fields. This patch modifies the default KEX profile to add support for extracting TX packet fields into MCAM search key. Enabled Tx KPU packet parsing by configuring TX PKIND in tx_parse_cfg. Also modified the default KEX profile to extract VLAN TCI from the LB_PTR and exact byte offset of VLAN header. The NPC KPU parser was modified to point LB_PTR to the starting byte offset of VLAN header which points to the tpid field. Signed-off-by: Stanislaw Kardach <redacted> Signed-off-by: Sunil Goutham <sgoutham@marvell.com> Signed-off-by: Naveen Mamindlapalli <redacted>A bit more documentation would be useful. However other than that the code itself appears to make sense. Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>quoted
--- .../ethernet/marvell/octeontx2/af/npc_profile.h | 71++++++++++++++++++++--quoted
.../net/ethernet/marvell/octeontx2/af/rvu_nix.c | 6 ++ 2 files changed, 72 insertions(+), 5 deletions(-)diff --git a/drivers/net/ethernet/marvell/octeontx2/af/npc_profile.hb/drivers/net/ethernet/marvell/octeontx2/af/npc_profile.h index 199448610e3e..c5b13385c81d 100644--- a/drivers/net/ethernet/marvell/octeontx2/af/npc_profile.h +++ b/drivers/net/ethernet/marvell/octeontx2/af/npc_profile.h@@ -13386,8 +13386,8 @@ static struct npc_mcam_kex npc_mkex_default ={quoted
.kpu_version = NPC_KPU_PROFILE_VER, .keyx_cfg = { /* nibble: LA..LE (ltype only) + Channel */ - [NIX_INTF_RX] = ((u64)NPC_MCAM_KEY_X2 << 32) | 0x49247, - [NIX_INTF_TX] = ((u64)NPC_MCAM_KEY_X2 << 32) | ((1ULL << 19) -1),quoted
+ [NIX_INTF_RX] = ((u64)NPC_MCAM_KEY_X2 << 32) | 0x249207, + [NIX_INTF_TX] = ((u64)NPC_MCAM_KEY_X2 << 32) | + 0x249200, }, .intf_lid_lt_ld = { /* Default RX MCAM KEX profile */// Any sort of explanation for what some of these magic numbers means might be useful. I'm left wondering if the lower 32b is a bitfield or a fixed value. I am guessing bit field based on the fact that it was originally being set using ((1ULL << X) - 1) however if there were macros defined for each bit explaining what each bit was that would be useful.
I will add the macros for each bit in v4.
quoted
@@ -13405,12 +13405,14 @@ static struct npc_mcam_kex npc_mkex_default= {quoted
/* Layer B: Single VLAN (CTAG) */ /* CTAG VLAN[2..3] + Ethertype, 4 bytes, KW0[63:32] */ [NPC_LT_LB_CTAG] = { - KEX_LD_CFG(0x03, 0x0, 0x1, 0x0, 0x4), + KEX_LD_CFG(0x03, 0x2, 0x1, 0x0, 0x4), },Similarly here some explanation for KEX_LD_CFG would be useful. From what I can tell it seems like this may be some sort of fix as you are adjusting the "hdr_ofs" field from 0 to 2.
The fix description is added in the commit msg. I will try to clarify a bit more in v4 commit description about the fix.
quoted
/* Layer B: Stacked VLAN (STAG|QinQ) */ [NPC_LT_LB_STAG_QINQ] = { - /* CTAG VLAN[2..3] + Ethertype, 4 bytes, KW0[63:32] */ - KEX_LD_CFG(0x03, 0x4, 0x1, 0x0, 0x4), + /* Outer VLAN: 2 bytes, KW0[63:48] */ + KEX_LD_CFG(0x01, 0x2, 0x1, 0x0, 0x6), + /* Ethertype: 2 bytes, KW0[47:32] */ + KEX_LD_CFG(0x01, 0x8, 0x1, 0x0, 0x4),Just to confirm, are you matching up the outer VLAN with the inner Ethertype here? It seems like an odd combination. I assume you need the inner ethertype in order to identify the L3 traffic?
In case of Q-in-Q, we are going to extract outer VLAN TCI 2 bytes and Ethertype (Ex: 0x0800 in case of IPv4) after CTAG Header. We don't support inner VLAN TCI match, so we don't extract.
quoted
}, [NPC_LT_LB_FDSA] = { /* SWITCH PORT: 1 byte, KW0[63:48] */@@ -13450,6 +13452,65 @@ static struct npc_mcam_kex npc_mkex_default= {quoted
}, }, }, + + /* Default TX MCAM KEX profile */ + [NIX_INTF_TX] = { + [NPC_LID_LA] = { + /* Layer A: Ethernet: */ + [NPC_LT_LA_IH_NIX_ETHER] = { + /* PF_FUNC: 2B , KW0 [47:32] */ + KEX_LD_CFG(0x01, 0x0, 0x1, 0x0, 0x4),I'm assuming you have an 8B internal header that is being parsed? A comment explaining that this is parsing a preamble that is at the start of things might be useful.
Will add in v4.
quoted
+ /* DMAC: 6 bytes, KW1[63:16] */ + KEX_LD_CFG(0x05, 0x8, 0x1, 0x0, 0xa), + }, + }, + [NPC_LID_LB] = { + /* Layer B: Single VLAN (CTAG) */ + [NPC_LT_LB_CTAG] = { + /* CTAG VLAN[2..3] KW0[63:48] */ + KEX_LD_CFG(0x01, 0x2, 0x1, 0x0, 0x6), + /* CTAG VLAN[2..3] KW1[15:0] */ + KEX_LD_CFG(0x01, 0x4, 0x1, 0x0, 0x8), + }, + /* Layer B: Stacked VLAN (STAG|QinQ) */ + [NPC_LT_LB_STAG_QINQ] = { + /* Outer VLAN: 2 bytes, KW0[63:48] */ + KEX_LD_CFG(0x01, 0x2, 0x1, 0x0, 0x6), + /* Outer VLAN: 2 Bytes, KW1[15:0] */ + KEX_LD_CFG(0x01, 0x8, 0x1, 0x0, 0x8), + }, + }, + [NPC_LID_LC] = { + /* Layer C: IPv4 */ + [NPC_LT_LC_IP] = { + /* SIP+DIP: 8 bytes, KW2[63:0] */ + KEX_LD_CFG(0x07, 0xc, 0x1, 0x0, 0x10), + /* TOS: 1 byte, KW1[63:56] */ + KEX_LD_CFG(0x0, 0x1, 0x1, 0x0, 0xf), + }, + /* Layer C: IPv6 */ + [NPC_LT_LC_IP6] = { + /* Everything up to SADDR: 8 bytes, KW2[63:0] */ + KEX_LD_CFG(0x07, 0x0, 0x1, 0x0, 0x10), + }, + }, + [NPC_LID_LD] = { + /* Layer D:UDP */ + [NPC_LT_LD_UDP] = { + /* SPORT: 2 bytes, KW3[15:0] */ + KEX_LD_CFG(0x1, 0x0, 0x1, 0x0, 0x18), + /* DPORT: 2 bytes, KW3[31:16] */ + KEX_LD_CFG(0x1, 0x2, 0x1, 0x0, 0x1a),I am curious why this is being done as two pieces instead of just one. From what I can tell you could just have a single rule that copies the 4 bytes for both ports in one shot and they would end up in the same place wouldn't they?
Yes correct, the will work. I will modify and push the changes in v4.
quoted
+ }, + /* Layer D:TCP */ + [NPC_LT_LD_TCP] = { + /* SPORT: 2 bytes, KW3[15:0] */ + KEX_LD_CFG(0x1, 0x0, 0x1, 0x0, 0x18), + /* DPORT: 2 bytes, KW3[31:16] */ + KEX_LD_CFG(0x1, 0x2, 0x1, 0x0, 0x1a), + }, + }, + }, }, };diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.cb/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c index 8bac1dd3a1c2..8c11abdbd9d1 100644--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c@@ -57,6 +57,8 @@ enum nix_makr_fmt_indexes { NIX_MARK_CFG_MAX, }; +#define NIX_TX_PKIND 63ULL +A comment explaining the magic number would be useful. From what I can tell this looks like a "just turn everything on" sort of config where you are enabling bit flags 0 - 5.
Sure, will add in v4.
quoted
/* For now considering MC resources needed for broadcast * pkt replication only. i.e 256 HWVFs + 12 PFs. */@@ -1182,6 +1184,10 @@ int rvu_mbox_handler_nix_lf_alloc(struct rvu *rvu, /* Config Rx pkt length, csum checks and apad enable / disable */ rvu_write64(rvu, blkaddr, NIX_AF_LFX_RX_CFG(nixlf),req->rx_cfg); + /* Configure pkind for TX parse config, 63 from npc_profile */ + cfg = NIX_TX_PKIND; + rvu_write64(rvu, blkaddr, NIX_AF_LFX_TX_PARSE_CFG(nixlf), + cfg); + intf = is_afvf(pcifunc) ? NIX_INTF_TYPE_LBK : NIX_INTF_TYPE_CGX; err = nix_interface_init(rvu, pcifunc, intf, nixlf); if (err) -- 2.16.5