netdev - RE: [Intel-wired-lan] [iwl-next v1] ice: add recipe priority check in search

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <PH0PR11MB50136A29D7ED13173A313FC2965C2@PH0PR11MB5013.namprd11.prod.outlook.com>
Date: Thu, 7 Nov 2024 12:06:26 +0000
From: "Buvaneswaran, Sujai" <sujai.buvaneswaran@...el.com>
To: Michal Swiatkowski <michal.swiatkowski@...ux.intel.com>,
	"intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "Szycik, Marcin"
	<marcin.szycik@...el.com>, "Kitszel, Przemyslaw"
	<przemyslaw.kitszel@...el.com>
Subject: RE: [Intel-wired-lan] [iwl-next v1] ice: add recipe priority check in
 search

> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@...osl.org> On Behalf Of
> Michal Swiatkowski
> Sent: Friday, October 11, 2024 12:33 PM
> To: intel-wired-lan@...ts.osuosl.org
> Cc: netdev@...r.kernel.org; Szycik, Marcin <marcin.szycik@...el.com>;
> Kitszel, Przemyslaw <przemyslaw.kitszel@...el.com>
> Subject: [Intel-wired-lan] [iwl-next v1] ice: add recipe priority check in search
> 
> The new recipe should be added even if exactly the same recipe already
> exists with different priority.
> 
> Example use case is when the rule is being added from TC tool context.
> It should has the highest priority, but if the recipe already exists the rule will
> inherit it priority. It can lead to the situation when the rule added from TC
> tool has lower priority than expected.
> 
> The solution is to check the recipe priority when trying to find existing one.
> 
> Previous recipe is still useful. Example:
> RID 8 -> priority 4
> RID 10 -> priority 7
> 
> The difference is only in priority rest is let's say eth + mac + direction.
> 
> Adding ARP + MAC_A + RX on RID 8, forward to VF0_VSI After that IP +
> MAC_B + RX on RID 10 (from TC tool), forward to PF0
> 
> Both will work.
> 
> In case of adding ARP + MAC_A + RX on RID 8, forward to VF0_VSI ARP +
> MAC_A + RX on RID 10, forward to PF0.
> 
> Only second one will match, but this is expected.
> 
> Reviewed-by: Marcin Szycik <marcin.szycik@...ux.intel.com>
> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@...el.com>
> Signed-off-by: Michal Swiatkowski <michal.swiatkowski@...ux.intel.com>
> ---
>  drivers/net/ethernet/intel/ice/ice_switch.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 

Hi,

I tried configuring two rules with same match parameters but with different priorities. One rule redirecting the PF traffic to VF_PR1 and other one to VF_PR2.

In this case, I notice that both the VFs are able to receive the same packet from the PF. Can you please confirm if this is expected?

Below are the rules (1 and 3) used.

[root@...-mariner ~]# tc filter show dev ens5f0np0 root
filter ingress protocol ip pref 1 flower chain 0 
filter ingress protocol ip pref 1 flower chain 0 handle 0x1 
  dst_mac 52:54:00:00:16:01
  src_mac b4:96:91:9f:65:58
  eth_type ipv4
  skip_sw
  in_hw in_hw_count 1
        action order 1: mirred (Egress Redirect to device eth0) stolen
        index 5 ref 1 bind 1

filter ingress protocol ip pref 1 flower chain 0 handle 0x2 
  dst_mac 52:54:00:00:16:02
  src_mac b4:96:91:9f:65:58
  eth_type ipv4
  skip_sw
  in_hw in_hw_count 1
        action order 1: mirred (Egress Redirect to device eth1) stolen
        index 6 ref 1 bind 1

filter ingress protocol ip pref 7 flower chain 0 
filter ingress protocol ip pref 7 flower chain 0 handle 0x1 
  dst_mac 52:54:00:00:16:01
  src_mac b4:96:91:9f:65:58
  eth_type ipv4
  skip_sw
  in_hw in_hw_count 1
        action order 1: mirred (Egress Redirect to device eth1) stolen
        index 7 ref 1 bind 1

Packet captures:
[root@...-mariner ~]# ip netns exec ns1 tcpdump -i ens5f0v0
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens5f0v0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:21:21.428973 STP 802.1w, Rapid STP, Flags [Proposal, Learn, Forward, Agreement], bridge-id 8001.18:5a:58:a3:1c:e0.8060, length 42
15:21:21.428986 STP 802.1w, Rapid STP, Flags [Proposal, Learn, Forward, Agreement], bridge-id 8001.18:5a:58:a3:1c:e0.8060, length 43
15:21:21.429001 STP 802.1w, Rapid STP, Flags [Proposal, Learn, Forward, Agreement], bridge-id 83e8.18:5a:58:a3:1c:e0.8060, length 42
15:21:21.429012 STP 802.1w, Rapid STP, Flags [Proposal, Learn, Forward, Agreement], bridge-id 83e9.18:5a:58:a3:1c:e0.8060, length 42
15:21:21.429016 STP 802.1w, Rapid STP, Flags [Proposal, Learn, Forward, Agreement], bridge-id 83ea.18:5a:58:a3:1c:e0.8060, length 42
15:21:21.429029 STP 802.1w, Rapid STP, Flags [Proposal, Learn, Forward, Agreement], bridge-id 83eb.18:5a:58:a3:1c:e0.8060, length 42
15:21:21.429039 STP 802.1w, Rapid STP, Flags [Proposal, Learn, Forward, Agreement], bridge-id 80c8.18:5a:58:a3:1c:e0.8060, length 42
15:21:21.944173 IP 1.1.1.100 > cbl-mariner: ICMP echo request, id 7, seq 4268, length 64
15:21:21.944182 IP cbl-mariner > 1.1.1.100: ICMP echo reply, id 7, seq 4268, length 64
^C
9 packets captured
9 packets received by filter
0 packets dropped by kernel

[root@...-mariner ~]# ip netns exec ns2 tcpdump -i ens5f0v1
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens5f0v1, link-type EN10MB (Ethernet), capture size 262144 bytes
15:21:21.429028 STP 802.1w, Rapid STP, Flags [Proposal, Learn, Forward, Agreement], bridge-id 83eb.18:5a:58:a3:1c:e0.8060, length 42
15:21:21.429040 STP 802.1w, Rapid STP, Flags [Proposal, Learn, Forward, Agreement], bridge-id 80c8.18:5a:58:a3:1c:e0.8060, length 42
15:21:21.944170 IP 1.1.1.100 > 1.1.1.1: ICMP echo request, id 7, seq 4268, length 64
15:21:22.968162 IP 1.1.1.100 > 1.1.1.1: ICMP echo request, id 7, seq 4269, length 64
15:21:23.432386 STP 802.1w, Rapid STP, Flags [Proposal, Learn, Forward, Agreement], bridge-id 8001.18:5a:58:a3:1c:e0.8060, length 42
15:21:23.432403 STP 802.1w, Rapid STP, Flags [Proposal, Learn, Forward, Agreement], bridge-id 8001.18:5a:58:a3:1c:e0.8060, length 43
15:21:23.432430 STP 802.1w, Rapid STP, Flags [Proposal, Learn, Forward, Agreement], bridge-id 83e8.18:5a:58:a3:1c:e0.8060, length 42
15:21:23.432472 STP 802.1w, Rapid STP, Flags [Proposal, Learn, Forward, Agreement], bridge-id 83e9.18:5a:58:a3:1c:e0.8060, length 42
15:21:23.432508 STP 802.1w, Rapid STP, Flags [Proposal, Learn, Forward, Agreement], bridge-id 83ea.18:5a:58:a3:1c:e0.8060, length 42
15:21:23.432549 STP 802.1w, Rapid STP, Flags [Proposal, Learn, Forward, Agreement], bridge-id 83eb.18:5a:58:a3:1c:e0.8060, length 42
15:21:23.432588 STP 802.1w, Rapid STP, Flags [Proposal, Learn, Forward, Agreement], bridge-id 80c8.18:5a:58:a3:1c:e0.8060, length 42
15:21:23.992156 IP 1.1.1.100 > 1.1.1.1: ICMP echo request, id 7, seq 4270, length 64

Regards,
Sujai B