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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Zy3jMhc4Bt1AYXod@mev-dev.igk.intel.com>
Date: Fri, 8 Nov 2024 11:08:50 +0100
From: Michal Swiatkowski <michal.swiatkowski@...ux.intel.com>
To: "Buvaneswaran, Sujai" <sujai.buvaneswaran@...el.com>
Cc: "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
	"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

On Thu, Nov 07, 2024 at 12:06:26PM +0000, Buvaneswaran, Sujai wrote:
> > -----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
> 

Hi,

Yes, it is expected. We don't support different priority from tc yet, so
no matter what priority from tc you will choose it will be programmed
with the same priority in hw.

Thanks,
Michal

> Regards,
> Sujai B