* [Intel-wired-lan] [PATCH iwl-next 0/2] ice: Direction metadata in tc filter @ 2023-06-22 13:35 ` Marcin Szycik 0 siblings, 0 replies; 14+ messages in thread From: Marcin Szycik @ 2023-06-22 13:35 UTC (permalink / raw) To: intel-wired-lan; +Cc: netdev Add matching on direction metadata when adding a filter via tc. Also rename related enum values for readability. Marcin Szycik (2): ice: Add direction metadata ice: Rename enum ice_pkt_flags values .../ethernet/intel/ice/ice_protocol_type.h | 9 ++--- drivers/net/ethernet/intel/ice/ice_switch.c | 11 ++++-- drivers/net/ethernet/intel/ice/ice_switch.h | 1 + drivers/net/ethernet/intel/ice/ice_tc_lib.c | 34 +++++++++---------- 4 files changed, 32 insertions(+), 23 deletions(-) -- 2.31.1 _______________________________________________ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH iwl-next 0/2] ice: Direction metadata in tc filter @ 2023-06-22 13:35 ` Marcin Szycik 0 siblings, 0 replies; 14+ messages in thread From: Marcin Szycik @ 2023-06-22 13:35 UTC (permalink / raw) To: intel-wired-lan; +Cc: netdev, Marcin Szycik Add matching on direction metadata when adding a filter via tc. Also rename related enum values for readability. Marcin Szycik (2): ice: Add direction metadata ice: Rename enum ice_pkt_flags values .../ethernet/intel/ice/ice_protocol_type.h | 9 ++--- drivers/net/ethernet/intel/ice/ice_switch.c | 11 ++++-- drivers/net/ethernet/intel/ice/ice_switch.h | 1 + drivers/net/ethernet/intel/ice/ice_tc_lib.c | 34 +++++++++---------- 4 files changed, 32 insertions(+), 23 deletions(-) -- 2.31.1 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Intel-wired-lan] [PATCH iwl-next 1/2] ice: Add direction metadata 2023-06-22 13:35 ` Marcin Szycik @ 2023-06-22 13:35 ` Marcin Szycik -1 siblings, 0 replies; 14+ messages in thread From: Marcin Szycik @ 2023-06-22 13:35 UTC (permalink / raw) To: intel-wired-lan; +Cc: netdev Currently it is possible to create a filter which breaks TX traffic, e.g.: tc filter add dev $PF1 ingress protocol ip prio 1 flower ip_proto udp dst_port $PORT action mirred egress redirect dev $VF1_PR This adds a rule which might match both TX and RX traffic, and in TX path the PF will actually receive the traffic, which breaks communication. To fix this, add a match on direction metadata flag when adding a tc rule. Because of the way metadata is currently handled, a duplicate lookup word would appear if VLAN metadata is also added. The lookup would still work correctly, but one word would be wasted. To prevent it, lookup 0 now always contains all metadata. When any metadata needs to be added, it is added to lookup 0 and lookup count is not incremented. This way, two flags residing in the same word will take up one word, instead of two. Note: the drop action is also affected, i.e. it will now only work in one direction. Signed-off-by: Marcin Szycik <marcin.szycik@linux.intel.com> --- .../ethernet/intel/ice/ice_protocol_type.h | 1 + drivers/net/ethernet/intel/ice/ice_switch.c | 11 ++++-- drivers/net/ethernet/intel/ice/ice_switch.h | 1 + drivers/net/ethernet/intel/ice/ice_tc_lib.c | 34 +++++++++---------- 4 files changed, 28 insertions(+), 19 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_protocol_type.h b/drivers/net/ethernet/intel/ice/ice_protocol_type.h index a1543e995fa1..82491f6af6d0 100644 --- a/drivers/net/ethernet/intel/ice/ice_protocol_type.h +++ b/drivers/net/ethernet/intel/ice/ice_protocol_type.h @@ -298,6 +298,7 @@ struct ice_nvgre_hdr { * M = EVLAN (0x8100) - Outer L2 header has EVLAN (ethernet type 0x8100) * N = EVLAN (0x9100) - Outer L2 header has EVLAN (ethernet type 0x9100) */ +#define ICE_PKT_FROM_NETWORK BIT(3) #define ICE_PKT_VLAN_STAG BIT(12) #define ICE_PKT_VLAN_ITAG BIT(13) #define ICE_PKT_VLAN_EVLAN (BIT(14) | BIT(15)) diff --git a/drivers/net/ethernet/intel/ice/ice_switch.c b/drivers/net/ethernet/intel/ice/ice_switch.c index 87d5ce0c8cb3..28fb175f0fe4 100644 --- a/drivers/net/ethernet/intel/ice/ice_switch.c +++ b/drivers/net/ethernet/intel/ice/ice_switch.c @@ -6143,14 +6143,21 @@ ice_adv_add_update_vsi_list(struct ice_hw *hw, void ice_rule_add_tunnel_metadata(struct ice_adv_lkup_elem *lkup) { lkup->type = ICE_HW_METADATA; - lkup->m_u.metadata.flags[ICE_PKT_FLAGS_TUNNEL] = + lkup->m_u.metadata.flags[ICE_PKT_FLAGS_TUNNEL] |= cpu_to_be16(ICE_PKT_TUNNEL_MASK); } +void ice_rule_add_direction_metadata(struct ice_adv_lkup_elem *lkup) +{ + lkup->type = ICE_HW_METADATA; + lkup->m_u.metadata.flags[ICE_PKT_FLAGS_VLAN] |= + cpu_to_be16(ICE_PKT_FROM_NETWORK); +} + void ice_rule_add_vlan_metadata(struct ice_adv_lkup_elem *lkup) { lkup->type = ICE_HW_METADATA; - lkup->m_u.metadata.flags[ICE_PKT_FLAGS_VLAN] = + lkup->m_u.metadata.flags[ICE_PKT_FLAGS_VLAN] |= cpu_to_be16(ICE_PKT_VLAN_MASK); } diff --git a/drivers/net/ethernet/intel/ice/ice_switch.h b/drivers/net/ethernet/intel/ice/ice_switch.h index f2ff8fbfe9b6..ee24707071a1 100644 --- a/drivers/net/ethernet/intel/ice/ice_switch.h +++ b/drivers/net/ethernet/intel/ice/ice_switch.h @@ -361,6 +361,7 @@ int ice_share_res(struct ice_hw *hw, u16 type, u8 shared, u16 res_id); /* Switch/bridge related commands */ void ice_rule_add_tunnel_metadata(struct ice_adv_lkup_elem *lkup); +void ice_rule_add_direction_metadata(struct ice_adv_lkup_elem *lkup); void ice_rule_add_vlan_metadata(struct ice_adv_lkup_elem *lkup); void ice_rule_add_src_vsi_metadata(struct ice_adv_lkup_elem *lkup); int diff --git a/drivers/net/ethernet/intel/ice/ice_tc_lib.c b/drivers/net/ethernet/intel/ice/ice_tc_lib.c index 6bbf99b5e112..c4a14eaacc5c 100644 --- a/drivers/net/ethernet/intel/ice/ice_tc_lib.c +++ b/drivers/net/ethernet/intel/ice/ice_tc_lib.c @@ -7,6 +7,8 @@ #include "ice_lib.h" #include "ice_protocol_type.h" +#define ICE_TC_METADATA_LKUP_IDX 0 + /** * ice_tc_count_lkups - determine lookup count for switch filter * @flags: TC-flower flags @@ -19,7 +21,13 @@ static int ice_tc_count_lkups(u32 flags, struct ice_tc_flower_lyr_2_4_hdrs *headers, struct ice_tc_flower_fltr *fltr) { - int lkups_cnt = 0; + int lkups_cnt = 1; /* 0th lookup is metadata */ + + /* Always add metadata as the 0th lookup. Included elements: + * - Direction flag (always present) + * - ICE_TC_FLWR_FIELD_VLAN_TPID (present if specified) + * - Tunnel flag (present if tunnel) + */ if (flags & ICE_TC_FLWR_FIELD_TENANT_ID) lkups_cnt++; @@ -57,10 +65,6 @@ ice_tc_count_lkups(u32 flags, struct ice_tc_flower_lyr_2_4_hdrs *headers, if (flags & (ICE_TC_FLWR_FIELD_VLAN | ICE_TC_FLWR_FIELD_VLAN_PRIO)) lkups_cnt++; - /* is VLAN TPID specified */ - if (flags & ICE_TC_FLWR_FIELD_VLAN_TPID) - lkups_cnt++; - /* is CVLAN specified? */ if (flags & (ICE_TC_FLWR_FIELD_CVLAN | ICE_TC_FLWR_FIELD_CVLAN_PRIO)) lkups_cnt++; @@ -87,10 +91,6 @@ ice_tc_count_lkups(u32 flags, struct ice_tc_flower_lyr_2_4_hdrs *headers, ICE_TC_FLWR_FIELD_SRC_L4_PORT)) lkups_cnt++; - /* matching for tunneled packets in metadata */ - if (fltr->tunnel_type != TNL_LAST) - lkups_cnt++; - return lkups_cnt; } @@ -183,10 +183,9 @@ static u16 ice_check_supported_vlan_tpid(u16 vlan_tpid) static int ice_tc_fill_tunnel_outer(u32 flags, struct ice_tc_flower_fltr *fltr, - struct ice_adv_lkup_elem *list) + struct ice_adv_lkup_elem *list, int i) { struct ice_tc_flower_lyr_2_4_hdrs *hdr = &fltr->outer_headers; - int i = 0; if (flags & ICE_TC_FLWR_FIELD_TENANT_ID) { u32 tenant_id; @@ -351,8 +350,7 @@ ice_tc_fill_tunnel_outer(u32 flags, struct ice_tc_flower_fltr *fltr, } /* always fill matching on tunneled packets in metadata */ - ice_rule_add_tunnel_metadata(&list[i]); - i++; + ice_rule_add_tunnel_metadata(&list[ICE_TC_METADATA_LKUP_IDX]); return i; } @@ -380,13 +378,16 @@ ice_tc_fill_rules(struct ice_hw *hw, u32 flags, struct ice_tc_flower_lyr_2_4_hdrs *headers = &tc_fltr->outer_headers; bool inner = false; u16 vlan_tpid = 0; - int i = 0; + int i = 1; /* 0th lookup is metadata */ rule_info->vlan_type = vlan_tpid; + /* Always add direction metadata */ + ice_rule_add_direction_metadata(&list[ICE_TC_METADATA_LKUP_IDX]); + rule_info->tun_type = ice_sw_type_from_tunnel(tc_fltr->tunnel_type); if (tc_fltr->tunnel_type != TNL_LAST) { - i = ice_tc_fill_tunnel_outer(flags, tc_fltr, list); + i = ice_tc_fill_tunnel_outer(flags, tc_fltr, list, i); /* PFCP is considered non-tunneled - don't swap headers. */ if (tc_fltr->tunnel_type != TNL_PFCP) { @@ -456,8 +457,7 @@ ice_tc_fill_rules(struct ice_hw *hw, u32 flags, rule_info->vlan_type = ice_check_supported_vlan_tpid(vlan_tpid); - ice_rule_add_vlan_metadata(&list[i]); - i++; + ice_rule_add_vlan_metadata(&list[ICE_TC_METADATA_LKUP_IDX]); } if (flags & (ICE_TC_FLWR_FIELD_CVLAN | ICE_TC_FLWR_FIELD_CVLAN_PRIO)) { -- 2.31.1 _______________________________________________ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH iwl-next 1/2] ice: Add direction metadata @ 2023-06-22 13:35 ` Marcin Szycik 0 siblings, 0 replies; 14+ messages in thread From: Marcin Szycik @ 2023-06-22 13:35 UTC (permalink / raw) To: intel-wired-lan; +Cc: netdev, Marcin Szycik Currently it is possible to create a filter which breaks TX traffic, e.g.: tc filter add dev $PF1 ingress protocol ip prio 1 flower ip_proto udp dst_port $PORT action mirred egress redirect dev $VF1_PR This adds a rule which might match both TX and RX traffic, and in TX path the PF will actually receive the traffic, which breaks communication. To fix this, add a match on direction metadata flag when adding a tc rule. Because of the way metadata is currently handled, a duplicate lookup word would appear if VLAN metadata is also added. The lookup would still work correctly, but one word would be wasted. To prevent it, lookup 0 now always contains all metadata. When any metadata needs to be added, it is added to lookup 0 and lookup count is not incremented. This way, two flags residing in the same word will take up one word, instead of two. Note: the drop action is also affected, i.e. it will now only work in one direction. Signed-off-by: Marcin Szycik <marcin.szycik@linux.intel.com> --- .../ethernet/intel/ice/ice_protocol_type.h | 1 + drivers/net/ethernet/intel/ice/ice_switch.c | 11 ++++-- drivers/net/ethernet/intel/ice/ice_switch.h | 1 + drivers/net/ethernet/intel/ice/ice_tc_lib.c | 34 +++++++++---------- 4 files changed, 28 insertions(+), 19 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_protocol_type.h b/drivers/net/ethernet/intel/ice/ice_protocol_type.h index a1543e995fa1..82491f6af6d0 100644 --- a/drivers/net/ethernet/intel/ice/ice_protocol_type.h +++ b/drivers/net/ethernet/intel/ice/ice_protocol_type.h @@ -298,6 +298,7 @@ struct ice_nvgre_hdr { * M = EVLAN (0x8100) - Outer L2 header has EVLAN (ethernet type 0x8100) * N = EVLAN (0x9100) - Outer L2 header has EVLAN (ethernet type 0x9100) */ +#define ICE_PKT_FROM_NETWORK BIT(3) #define ICE_PKT_VLAN_STAG BIT(12) #define ICE_PKT_VLAN_ITAG BIT(13) #define ICE_PKT_VLAN_EVLAN (BIT(14) | BIT(15)) diff --git a/drivers/net/ethernet/intel/ice/ice_switch.c b/drivers/net/ethernet/intel/ice/ice_switch.c index 87d5ce0c8cb3..28fb175f0fe4 100644 --- a/drivers/net/ethernet/intel/ice/ice_switch.c +++ b/drivers/net/ethernet/intel/ice/ice_switch.c @@ -6143,14 +6143,21 @@ ice_adv_add_update_vsi_list(struct ice_hw *hw, void ice_rule_add_tunnel_metadata(struct ice_adv_lkup_elem *lkup) { lkup->type = ICE_HW_METADATA; - lkup->m_u.metadata.flags[ICE_PKT_FLAGS_TUNNEL] = + lkup->m_u.metadata.flags[ICE_PKT_FLAGS_TUNNEL] |= cpu_to_be16(ICE_PKT_TUNNEL_MASK); } +void ice_rule_add_direction_metadata(struct ice_adv_lkup_elem *lkup) +{ + lkup->type = ICE_HW_METADATA; + lkup->m_u.metadata.flags[ICE_PKT_FLAGS_VLAN] |= + cpu_to_be16(ICE_PKT_FROM_NETWORK); +} + void ice_rule_add_vlan_metadata(struct ice_adv_lkup_elem *lkup) { lkup->type = ICE_HW_METADATA; - lkup->m_u.metadata.flags[ICE_PKT_FLAGS_VLAN] = + lkup->m_u.metadata.flags[ICE_PKT_FLAGS_VLAN] |= cpu_to_be16(ICE_PKT_VLAN_MASK); } diff --git a/drivers/net/ethernet/intel/ice/ice_switch.h b/drivers/net/ethernet/intel/ice/ice_switch.h index f2ff8fbfe9b6..ee24707071a1 100644 --- a/drivers/net/ethernet/intel/ice/ice_switch.h +++ b/drivers/net/ethernet/intel/ice/ice_switch.h @@ -361,6 +361,7 @@ int ice_share_res(struct ice_hw *hw, u16 type, u8 shared, u16 res_id); /* Switch/bridge related commands */ void ice_rule_add_tunnel_metadata(struct ice_adv_lkup_elem *lkup); +void ice_rule_add_direction_metadata(struct ice_adv_lkup_elem *lkup); void ice_rule_add_vlan_metadata(struct ice_adv_lkup_elem *lkup); void ice_rule_add_src_vsi_metadata(struct ice_adv_lkup_elem *lkup); int diff --git a/drivers/net/ethernet/intel/ice/ice_tc_lib.c b/drivers/net/ethernet/intel/ice/ice_tc_lib.c index 6bbf99b5e112..c4a14eaacc5c 100644 --- a/drivers/net/ethernet/intel/ice/ice_tc_lib.c +++ b/drivers/net/ethernet/intel/ice/ice_tc_lib.c @@ -7,6 +7,8 @@ #include "ice_lib.h" #include "ice_protocol_type.h" +#define ICE_TC_METADATA_LKUP_IDX 0 + /** * ice_tc_count_lkups - determine lookup count for switch filter * @flags: TC-flower flags @@ -19,7 +21,13 @@ static int ice_tc_count_lkups(u32 flags, struct ice_tc_flower_lyr_2_4_hdrs *headers, struct ice_tc_flower_fltr *fltr) { - int lkups_cnt = 0; + int lkups_cnt = 1; /* 0th lookup is metadata */ + + /* Always add metadata as the 0th lookup. Included elements: + * - Direction flag (always present) + * - ICE_TC_FLWR_FIELD_VLAN_TPID (present if specified) + * - Tunnel flag (present if tunnel) + */ if (flags & ICE_TC_FLWR_FIELD_TENANT_ID) lkups_cnt++; @@ -57,10 +65,6 @@ ice_tc_count_lkups(u32 flags, struct ice_tc_flower_lyr_2_4_hdrs *headers, if (flags & (ICE_TC_FLWR_FIELD_VLAN | ICE_TC_FLWR_FIELD_VLAN_PRIO)) lkups_cnt++; - /* is VLAN TPID specified */ - if (flags & ICE_TC_FLWR_FIELD_VLAN_TPID) - lkups_cnt++; - /* is CVLAN specified? */ if (flags & (ICE_TC_FLWR_FIELD_CVLAN | ICE_TC_FLWR_FIELD_CVLAN_PRIO)) lkups_cnt++; @@ -87,10 +91,6 @@ ice_tc_count_lkups(u32 flags, struct ice_tc_flower_lyr_2_4_hdrs *headers, ICE_TC_FLWR_FIELD_SRC_L4_PORT)) lkups_cnt++; - /* matching for tunneled packets in metadata */ - if (fltr->tunnel_type != TNL_LAST) - lkups_cnt++; - return lkups_cnt; } @@ -183,10 +183,9 @@ static u16 ice_check_supported_vlan_tpid(u16 vlan_tpid) static int ice_tc_fill_tunnel_outer(u32 flags, struct ice_tc_flower_fltr *fltr, - struct ice_adv_lkup_elem *list) + struct ice_adv_lkup_elem *list, int i) { struct ice_tc_flower_lyr_2_4_hdrs *hdr = &fltr->outer_headers; - int i = 0; if (flags & ICE_TC_FLWR_FIELD_TENANT_ID) { u32 tenant_id; @@ -351,8 +350,7 @@ ice_tc_fill_tunnel_outer(u32 flags, struct ice_tc_flower_fltr *fltr, } /* always fill matching on tunneled packets in metadata */ - ice_rule_add_tunnel_metadata(&list[i]); - i++; + ice_rule_add_tunnel_metadata(&list[ICE_TC_METADATA_LKUP_IDX]); return i; } @@ -380,13 +378,16 @@ ice_tc_fill_rules(struct ice_hw *hw, u32 flags, struct ice_tc_flower_lyr_2_4_hdrs *headers = &tc_fltr->outer_headers; bool inner = false; u16 vlan_tpid = 0; - int i = 0; + int i = 1; /* 0th lookup is metadata */ rule_info->vlan_type = vlan_tpid; + /* Always add direction metadata */ + ice_rule_add_direction_metadata(&list[ICE_TC_METADATA_LKUP_IDX]); + rule_info->tun_type = ice_sw_type_from_tunnel(tc_fltr->tunnel_type); if (tc_fltr->tunnel_type != TNL_LAST) { - i = ice_tc_fill_tunnel_outer(flags, tc_fltr, list); + i = ice_tc_fill_tunnel_outer(flags, tc_fltr, list, i); /* PFCP is considered non-tunneled - don't swap headers. */ if (tc_fltr->tunnel_type != TNL_PFCP) { @@ -456,8 +457,7 @@ ice_tc_fill_rules(struct ice_hw *hw, u32 flags, rule_info->vlan_type = ice_check_supported_vlan_tpid(vlan_tpid); - ice_rule_add_vlan_metadata(&list[i]); - i++; + ice_rule_add_vlan_metadata(&list[ICE_TC_METADATA_LKUP_IDX]); } if (flags & (ICE_TC_FLWR_FIELD_CVLAN | ICE_TC_FLWR_FIELD_CVLAN_PRIO)) { -- 2.31.1 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [Intel-wired-lan] [PATCH iwl-next 1/2] ice: Add direction metadata 2023-06-22 13:35 ` Marcin Szycik @ 2023-06-23 7:25 ` Simon Horman -1 siblings, 0 replies; 14+ messages in thread From: Simon Horman @ 2023-06-23 7:25 UTC (permalink / raw) To: Marcin Szycik; +Cc: netdev, intel-wired-lan On Thu, Jun 22, 2023 at 03:35:12PM +0200, Marcin Szycik wrote: > Currently it is possible to create a filter which breaks TX traffic, e.g.: > > tc filter add dev $PF1 ingress protocol ip prio 1 flower ip_proto udp > dst_port $PORT action mirred egress redirect dev $VF1_PR > > This adds a rule which might match both TX and RX traffic, and in TX path > the PF will actually receive the traffic, which breaks communication. > > To fix this, add a match on direction metadata flag when adding a tc rule. > > Because of the way metadata is currently handled, a duplicate lookup word > would appear if VLAN metadata is also added. The lookup would still work > correctly, but one word would be wasted. To prevent it, lookup 0 now always > contains all metadata. When any metadata needs to be added, it is added to > lookup 0 and lookup count is not incremented. This way, two flags residing > in the same word will take up one word, instead of two. > > Note: the drop action is also affected, i.e. it will now only work in one > direction. > > Signed-off-by: Marcin Szycik <marcin.szycik@linux.intel.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> _______________________________________________ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH iwl-next 1/2] ice: Add direction metadata @ 2023-06-23 7:25 ` Simon Horman 0 siblings, 0 replies; 14+ messages in thread From: Simon Horman @ 2023-06-23 7:25 UTC (permalink / raw) To: Marcin Szycik; +Cc: intel-wired-lan, netdev On Thu, Jun 22, 2023 at 03:35:12PM +0200, Marcin Szycik wrote: > Currently it is possible to create a filter which breaks TX traffic, e.g.: > > tc filter add dev $PF1 ingress protocol ip prio 1 flower ip_proto udp > dst_port $PORT action mirred egress redirect dev $VF1_PR > > This adds a rule which might match both TX and RX traffic, and in TX path > the PF will actually receive the traffic, which breaks communication. > > To fix this, add a match on direction metadata flag when adding a tc rule. > > Because of the way metadata is currently handled, a duplicate lookup word > would appear if VLAN metadata is also added. The lookup would still work > correctly, but one word would be wasted. To prevent it, lookup 0 now always > contains all metadata. When any metadata needs to be added, it is added to > lookup 0 and lookup count is not incremented. This way, two flags residing > in the same word will take up one word, instead of two. > > Note: the drop action is also affected, i.e. it will now only work in one > direction. > > Signed-off-by: Marcin Szycik <marcin.szycik@linux.intel.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Intel-wired-lan] [PATCH iwl-next 1/2] ice: Add direction metadata 2023-06-22 13:35 ` Marcin Szycik @ 2023-07-03 11:50 ` Buvaneswaran, Sujai -1 siblings, 0 replies; 14+ messages in thread From: Buvaneswaran, Sujai @ 2023-07-03 11:50 UTC (permalink / raw) To: Marcin Szycik, intel-wired-lan@lists.osuosl.org; +Cc: netdev@vger.kernel.org > -----Original Message----- > From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of > Marcin Szycik > Sent: Thursday, June 22, 2023 7:05 PM > To: intel-wired-lan@lists.osuosl.org > Cc: netdev@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH iwl-next 1/2] ice: Add direction metadata > > Currently it is possible to create a filter which breaks TX traffic, e.g.: > > tc filter add dev $PF1 ingress protocol ip prio 1 flower ip_proto udp dst_port > $PORT action mirred egress redirect dev $VF1_PR > > This adds a rule which might match both TX and RX traffic, and in TX path the > PF will actually receive the traffic, which breaks communication. > > To fix this, add a match on direction metadata flag when adding a tc rule. > > Because of the way metadata is currently handled, a duplicate lookup word > would appear if VLAN metadata is also added. The lookup would still work > correctly, but one word would be wasted. To prevent it, lookup 0 now always > contains all metadata. When any metadata needs to be added, it is added to > lookup 0 and lookup count is not incremented. This way, two flags residing in > the same word will take up one word, instead of two. > > Note: the drop action is also affected, i.e. it will now only work in one > direction. > > Signed-off-by: Marcin Szycik <marcin.szycik@linux.intel.com> > --- > .../ethernet/intel/ice/ice_protocol_type.h | 1 + > drivers/net/ethernet/intel/ice/ice_switch.c | 11 ++++-- > drivers/net/ethernet/intel/ice/ice_switch.h | 1 + > drivers/net/ethernet/intel/ice/ice_tc_lib.c | 34 +++++++++---------- > 4 files changed, 28 insertions(+), 19 deletions(-) > Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com> _______________________________________________ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: [Intel-wired-lan] [PATCH iwl-next 1/2] ice: Add direction metadata @ 2023-07-03 11:50 ` Buvaneswaran, Sujai 0 siblings, 0 replies; 14+ messages in thread From: Buvaneswaran, Sujai @ 2023-07-03 11:50 UTC (permalink / raw) To: Marcin Szycik, intel-wired-lan@lists.osuosl.org; +Cc: netdev@vger.kernel.org > -----Original Message----- > From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of > Marcin Szycik > Sent: Thursday, June 22, 2023 7:05 PM > To: intel-wired-lan@lists.osuosl.org > Cc: netdev@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH iwl-next 1/2] ice: Add direction metadata > > Currently it is possible to create a filter which breaks TX traffic, e.g.: > > tc filter add dev $PF1 ingress protocol ip prio 1 flower ip_proto udp dst_port > $PORT action mirred egress redirect dev $VF1_PR > > This adds a rule which might match both TX and RX traffic, and in TX path the > PF will actually receive the traffic, which breaks communication. > > To fix this, add a match on direction metadata flag when adding a tc rule. > > Because of the way metadata is currently handled, a duplicate lookup word > would appear if VLAN metadata is also added. The lookup would still work > correctly, but one word would be wasted. To prevent it, lookup 0 now always > contains all metadata. When any metadata needs to be added, it is added to > lookup 0 and lookup count is not incremented. This way, two flags residing in > the same word will take up one word, instead of two. > > Note: the drop action is also affected, i.e. it will now only work in one > direction. > > Signed-off-by: Marcin Szycik <marcin.szycik@linux.intel.com> > --- > .../ethernet/intel/ice/ice_protocol_type.h | 1 + > drivers/net/ethernet/intel/ice/ice_switch.c | 11 ++++-- > drivers/net/ethernet/intel/ice/ice_switch.h | 1 + > drivers/net/ethernet/intel/ice/ice_tc_lib.c | 34 +++++++++---------- > 4 files changed, 28 insertions(+), 19 deletions(-) > Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com> ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Intel-wired-lan] [PATCH iwl-next 2/2] ice: Rename enum ice_pkt_flags values 2023-06-22 13:35 ` Marcin Szycik @ 2023-06-22 13:35 ` Marcin Szycik -1 siblings, 0 replies; 14+ messages in thread From: Marcin Szycik @ 2023-06-22 13:35 UTC (permalink / raw) To: intel-wired-lan; +Cc: netdev enum ice_pkt_flags contains values such as ICE_PKT_FLAGS_VLAN and ICE_PKT_FLAGS_TUNNEL, but actually the flags words which they refer to contain a range of unrelated values - e.g. word 0 (ICE_PKT_FLAGS_VLAN) contains fields such as from_network and ucast, which have nothing to do with VLAN. Rename each enum value to ICE_PKT_FLAGS_MDID<number>, so it's clear in which flags word does some value reside. Signed-off-by: Marcin Szycik <marcin.szycik@linux.intel.com> --- drivers/net/ethernet/intel/ice/ice_protocol_type.h | 8 ++++---- drivers/net/ethernet/intel/ice/ice_switch.c | 6 +++--- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_protocol_type.h b/drivers/net/ethernet/intel/ice/ice_protocol_type.h index 82491f6af6d0..755a9c55267c 100644 --- a/drivers/net/ethernet/intel/ice/ice_protocol_type.h +++ b/drivers/net/ethernet/intel/ice/ice_protocol_type.h @@ -404,10 +404,10 @@ enum ice_hw_metadata_offset { }; enum ice_pkt_flags { - ICE_PKT_FLAGS_VLAN = 0, - ICE_PKT_FLAGS_TUNNEL = 1, - ICE_PKT_FLAGS_TCP = 2, - ICE_PKT_FLAGS_ERROR = 3, + ICE_PKT_FLAGS_MDID20 = 0, + ICE_PKT_FLAGS_MDID21 = 1, + ICE_PKT_FLAGS_MDID22 = 2, + ICE_PKT_FLAGS_MDID23 = 3, }; struct ice_hw_metadata { diff --git a/drivers/net/ethernet/intel/ice/ice_switch.c b/drivers/net/ethernet/intel/ice/ice_switch.c index 28fb175f0fe4..f962d3350332 100644 --- a/drivers/net/ethernet/intel/ice/ice_switch.c +++ b/drivers/net/ethernet/intel/ice/ice_switch.c @@ -6143,21 +6143,21 @@ ice_adv_add_update_vsi_list(struct ice_hw *hw, void ice_rule_add_tunnel_metadata(struct ice_adv_lkup_elem *lkup) { lkup->type = ICE_HW_METADATA; - lkup->m_u.metadata.flags[ICE_PKT_FLAGS_TUNNEL] |= + lkup->m_u.metadata.flags[ICE_PKT_FLAGS_MDID21] |= cpu_to_be16(ICE_PKT_TUNNEL_MASK); } void ice_rule_add_direction_metadata(struct ice_adv_lkup_elem *lkup) { lkup->type = ICE_HW_METADATA; - lkup->m_u.metadata.flags[ICE_PKT_FLAGS_VLAN] |= + lkup->m_u.metadata.flags[ICE_PKT_FLAGS_MDID20] |= cpu_to_be16(ICE_PKT_FROM_NETWORK); } void ice_rule_add_vlan_metadata(struct ice_adv_lkup_elem *lkup) { lkup->type = ICE_HW_METADATA; - lkup->m_u.metadata.flags[ICE_PKT_FLAGS_VLAN] |= + lkup->m_u.metadata.flags[ICE_PKT_FLAGS_MDID20] |= cpu_to_be16(ICE_PKT_VLAN_MASK); } -- 2.31.1 _______________________________________________ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH iwl-next 2/2] ice: Rename enum ice_pkt_flags values @ 2023-06-22 13:35 ` Marcin Szycik 0 siblings, 0 replies; 14+ messages in thread From: Marcin Szycik @ 2023-06-22 13:35 UTC (permalink / raw) To: intel-wired-lan; +Cc: netdev, Marcin Szycik enum ice_pkt_flags contains values such as ICE_PKT_FLAGS_VLAN and ICE_PKT_FLAGS_TUNNEL, but actually the flags words which they refer to contain a range of unrelated values - e.g. word 0 (ICE_PKT_FLAGS_VLAN) contains fields such as from_network and ucast, which have nothing to do with VLAN. Rename each enum value to ICE_PKT_FLAGS_MDID<number>, so it's clear in which flags word does some value reside. Signed-off-by: Marcin Szycik <marcin.szycik@linux.intel.com> --- drivers/net/ethernet/intel/ice/ice_protocol_type.h | 8 ++++---- drivers/net/ethernet/intel/ice/ice_switch.c | 6 +++--- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_protocol_type.h b/drivers/net/ethernet/intel/ice/ice_protocol_type.h index 82491f6af6d0..755a9c55267c 100644 --- a/drivers/net/ethernet/intel/ice/ice_protocol_type.h +++ b/drivers/net/ethernet/intel/ice/ice_protocol_type.h @@ -404,10 +404,10 @@ enum ice_hw_metadata_offset { }; enum ice_pkt_flags { - ICE_PKT_FLAGS_VLAN = 0, - ICE_PKT_FLAGS_TUNNEL = 1, - ICE_PKT_FLAGS_TCP = 2, - ICE_PKT_FLAGS_ERROR = 3, + ICE_PKT_FLAGS_MDID20 = 0, + ICE_PKT_FLAGS_MDID21 = 1, + ICE_PKT_FLAGS_MDID22 = 2, + ICE_PKT_FLAGS_MDID23 = 3, }; struct ice_hw_metadata { diff --git a/drivers/net/ethernet/intel/ice/ice_switch.c b/drivers/net/ethernet/intel/ice/ice_switch.c index 28fb175f0fe4..f962d3350332 100644 --- a/drivers/net/ethernet/intel/ice/ice_switch.c +++ b/drivers/net/ethernet/intel/ice/ice_switch.c @@ -6143,21 +6143,21 @@ ice_adv_add_update_vsi_list(struct ice_hw *hw, void ice_rule_add_tunnel_metadata(struct ice_adv_lkup_elem *lkup) { lkup->type = ICE_HW_METADATA; - lkup->m_u.metadata.flags[ICE_PKT_FLAGS_TUNNEL] |= + lkup->m_u.metadata.flags[ICE_PKT_FLAGS_MDID21] |= cpu_to_be16(ICE_PKT_TUNNEL_MASK); } void ice_rule_add_direction_metadata(struct ice_adv_lkup_elem *lkup) { lkup->type = ICE_HW_METADATA; - lkup->m_u.metadata.flags[ICE_PKT_FLAGS_VLAN] |= + lkup->m_u.metadata.flags[ICE_PKT_FLAGS_MDID20] |= cpu_to_be16(ICE_PKT_FROM_NETWORK); } void ice_rule_add_vlan_metadata(struct ice_adv_lkup_elem *lkup) { lkup->type = ICE_HW_METADATA; - lkup->m_u.metadata.flags[ICE_PKT_FLAGS_VLAN] |= + lkup->m_u.metadata.flags[ICE_PKT_FLAGS_MDID20] |= cpu_to_be16(ICE_PKT_VLAN_MASK); } -- 2.31.1 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [Intel-wired-lan] [PATCH iwl-next 2/2] ice: Rename enum ice_pkt_flags values 2023-06-22 13:35 ` Marcin Szycik @ 2023-06-23 7:32 ` Simon Horman -1 siblings, 0 replies; 14+ messages in thread From: Simon Horman @ 2023-06-23 7:32 UTC (permalink / raw) To: Marcin Szycik; +Cc: netdev, intel-wired-lan On Thu, Jun 22, 2023 at 03:35:13PM +0200, Marcin Szycik wrote: > enum ice_pkt_flags contains values such as ICE_PKT_FLAGS_VLAN and > ICE_PKT_FLAGS_TUNNEL, but actually the flags words which they refer to > contain a range of unrelated values - e.g. word 0 (ICE_PKT_FLAGS_VLAN) > contains fields such as from_network and ucast, which have nothing to do > with VLAN. Rename each enum value to ICE_PKT_FLAGS_MDID<number>, so it's > clear in which flags word does some value reside. > > Signed-off-by: Marcin Szycik <marcin.szycik@linux.intel.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> _______________________________________________ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH iwl-next 2/2] ice: Rename enum ice_pkt_flags values @ 2023-06-23 7:32 ` Simon Horman 0 siblings, 0 replies; 14+ messages in thread From: Simon Horman @ 2023-06-23 7:32 UTC (permalink / raw) To: Marcin Szycik; +Cc: intel-wired-lan, netdev On Thu, Jun 22, 2023 at 03:35:13PM +0200, Marcin Szycik wrote: > enum ice_pkt_flags contains values such as ICE_PKT_FLAGS_VLAN and > ICE_PKT_FLAGS_TUNNEL, but actually the flags words which they refer to > contain a range of unrelated values - e.g. word 0 (ICE_PKT_FLAGS_VLAN) > contains fields such as from_network and ucast, which have nothing to do > with VLAN. Rename each enum value to ICE_PKT_FLAGS_MDID<number>, so it's > clear in which flags word does some value reside. > > Signed-off-by: Marcin Szycik <marcin.szycik@linux.intel.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Intel-wired-lan] [PATCH iwl-next 2/2] ice: Rename enum ice_pkt_flags values 2023-06-22 13:35 ` Marcin Szycik @ 2023-07-03 11:51 ` Buvaneswaran, Sujai -1 siblings, 0 replies; 14+ messages in thread From: Buvaneswaran, Sujai @ 2023-07-03 11:51 UTC (permalink / raw) To: Marcin Szycik, intel-wired-lan@lists.osuosl.org; +Cc: netdev@vger.kernel.org > -----Original Message----- > From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of > Marcin Szycik > Sent: Thursday, June 22, 2023 7:05 PM > To: intel-wired-lan@lists.osuosl.org > Cc: netdev@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH iwl-next 2/2] ice: Rename enum > ice_pkt_flags values > > enum ice_pkt_flags contains values such as ICE_PKT_FLAGS_VLAN and > ICE_PKT_FLAGS_TUNNEL, but actually the flags words which they refer to > contain a range of unrelated values - e.g. word 0 (ICE_PKT_FLAGS_VLAN) > contains fields such as from_network and ucast, which have nothing to do > with VLAN. Rename each enum value to ICE_PKT_FLAGS_MDID<number>, so > it's clear in which flags word does some value reside. > > Signed-off-by: Marcin Szycik <marcin.szycik@linux.intel.com> > --- > drivers/net/ethernet/intel/ice/ice_protocol_type.h | 8 ++++---- > drivers/net/ethernet/intel/ice/ice_switch.c | 6 +++--- > 2 files changed, 7 insertions(+), 7 deletions(-) > Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com> _______________________________________________ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: [Intel-wired-lan] [PATCH iwl-next 2/2] ice: Rename enum ice_pkt_flags values @ 2023-07-03 11:51 ` Buvaneswaran, Sujai 0 siblings, 0 replies; 14+ messages in thread From: Buvaneswaran, Sujai @ 2023-07-03 11:51 UTC (permalink / raw) To: Marcin Szycik, intel-wired-lan@lists.osuosl.org; +Cc: netdev@vger.kernel.org > -----Original Message----- > From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of > Marcin Szycik > Sent: Thursday, June 22, 2023 7:05 PM > To: intel-wired-lan@lists.osuosl.org > Cc: netdev@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH iwl-next 2/2] ice: Rename enum > ice_pkt_flags values > > enum ice_pkt_flags contains values such as ICE_PKT_FLAGS_VLAN and > ICE_PKT_FLAGS_TUNNEL, but actually the flags words which they refer to > contain a range of unrelated values - e.g. word 0 (ICE_PKT_FLAGS_VLAN) > contains fields such as from_network and ucast, which have nothing to do > with VLAN. Rename each enum value to ICE_PKT_FLAGS_MDID<number>, so > it's clear in which flags word does some value reside. > > Signed-off-by: Marcin Szycik <marcin.szycik@linux.intel.com> > --- > drivers/net/ethernet/intel/ice/ice_protocol_type.h | 8 ++++---- > drivers/net/ethernet/intel/ice/ice_switch.c | 6 +++--- > 2 files changed, 7 insertions(+), 7 deletions(-) > Tested-by: Sujai Buvaneswaran <sujai.buvaneswaran@intel.com> ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2023-07-03 11:52 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-06-22 13:35 [Intel-wired-lan] [PATCH iwl-next 0/2] ice: Direction metadata in tc filter Marcin Szycik 2023-06-22 13:35 ` Marcin Szycik 2023-06-22 13:35 ` [Intel-wired-lan] [PATCH iwl-next 1/2] ice: Add direction metadata Marcin Szycik 2023-06-22 13:35 ` Marcin Szycik 2023-06-23 7:25 ` [Intel-wired-lan] " Simon Horman 2023-06-23 7:25 ` Simon Horman 2023-07-03 11:50 ` [Intel-wired-lan] " Buvaneswaran, Sujai 2023-07-03 11:50 ` Buvaneswaran, Sujai 2023-06-22 13:35 ` [Intel-wired-lan] [PATCH iwl-next 2/2] ice: Rename enum ice_pkt_flags values Marcin Szycik 2023-06-22 13:35 ` Marcin Szycik 2023-06-23 7:32 ` [Intel-wired-lan] " Simon Horman 2023-06-23 7:32 ` Simon Horman 2023-07-03 11:51 ` [Intel-wired-lan] " Buvaneswaran, Sujai 2023-07-03 11:51 ` Buvaneswaran, Sujai
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.