https://bugs.dpdk.org/show_bug.cgi?id=1211

            Bug ID: 1211
           Summary: ice: 'eth / ipv4 / udp dst is XXX / mark' rte_flow not
                    marking any packet
           Product: DPDK
           Version: 23.03
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: ethdev
          Assignee: dev@dpdk.org
          Reporter: maxime.leroy@6wind.com
  Target Milestone: ---

Environment
-------------

distribution for host/vm: Ubuntu 22.04.2 LTS, kernel 5.15.0-67-generic
kernel driver: 1.10.1.2.2
firmware-version: 4.20 0x8001778a 1.3346.0
COMMS DDP: 1.3.37
ICE OS Default Package version 1.3.30.0
testpmd cmdline:  ./build/app/dpdk-testpmd --log-level=.*ice.*,debug
--legacy-mem -c 0x1110001110 -a 0000:17:00.0 -a 0000:17:00.1  --  -i
--nb-cores=5 --nb-ports=2 --total-num-mbufs=16384 --rxq=4 --txq=4
dpdk version:  22.11.1
NIC: Intel Corporation Ethernet Controller E810-C for QSFP 

Reproduction
------------


Configuration
.............

On dut device, test-pmd configuration:


testpmd> set fwd rxonly 
Set rxonly packet forwarding mode
testpmd> set verbose 1
Change verbose level from 0 to 
testpmd> flow create 0 ingress pattern eth  / ipv4 / udp dst is 42 / end 
actions mark id 4 / end
ice_fdir_cur_prof_conflict(): Profile already exists for flow type 1.
ice_fdir_rx_parsing_enable(): FDIR processing on RX set to 1
ice_flow_create(): Succeeded to create (1) flow
Flow rule #1 created
testpmd> start

Tester script:
# cat port-42.scapy 

port = 42
p = []
p += Ether(src='b8:ce:f6:83:b3:13',
dst='40:a6:b7:7d:43:90')/IP(dst='10.100.0.2', src='10.100.0.1')/UDP(dport=port,
sport=port)
sendp(p, iface="eth1", count=3, inter=0.1)


With dpdk 23.03
...............

Tester Machine:
 scapy < port-42.scapy 

...>>> >>> >>> >>> >>> 
Sent 3 packets.


Result:
testpmd> port 0/queue 1: received 1 packets
  src=B8:CE:F6:83:B3:13 - dst=40:A6:B7:7D:43:90 - pool=mb_pool_0 - type=0x0800
- length=60 - nb_segs=1 - RSS hash=0xa1658a75 - RSS queue=0x1 - hw ptype:
L2_ETHER L3_IPV4_EXT_UNKNOWN L4_UDP  - sw ptype: L2_ETHER L3_IPV4 L4_UDP  -
l2_len=14 - l3_len=20 - l4_len=8 - Receive queue=0x1
  ol_flags: RTE_MBUF_F_RX_RSS_HASH RTE_MBUF_F_RX_L4_CKSUM_GOOD
RTE_MBUF_F_RX_IP_CKSUM_GOOD RTE_MBUF_F_RX_OUTER_L4_CKSUM_GOOD 
port 0/queue 1: received 1 packets
  src=B8:CE:F6:83:B3:13 - dst=40:A6:B7:7D:43:90 - pool=mb_pool_0 - type=0x0800
- length=60 - nb_segs=1 - RSS hash=0xa1658a75 - RSS queue=0x1 - hw ptype:
L2_ETHER L3_IPV4_EXT_UNKNOWN L4_UDP  - sw ptype: L2_ETHER L3_IPV4 L4_UDP  -
l2_len=14 - l3_len=20 - l4_len=8 - Receive queue=0x1
  ol_flags: RTE_MBUF_F_RX_RSS_HASH RTE_MBUF_F_RX_L4_CKSUM_GOOD
RTE_MBUF_F_RX_IP_CKSUM_GOOD RTE_MBUF_F_RX_OUTER_L4_CKSUM_GOOD 
port 0/queue 1: received 1 packets
  src=B8:CE:F6:83:B3:13 - dst=40:A6:B7:7D:43:90 - pool=mb_pool_0 - type=0x0800
- length=60 - nb_segs=1 - RSS hash=0xa1658a75 - RSS queue=0x1 - hw ptype:
L2_ETHER L3_IPV4_EXT_UNKNOWN L4_UDP  - sw ptype: L2_ETHER L3_IPV4 L4_UDP  -
l2_len=14 - l3_len=20 - l4_len=8 - Receive queue=0x1
  ol_flags: RTE_MBUF_F_RX_RSS_HASH RTE_MBUF_F_RX_L4_CKSUM_GOOD
RTE_MBUF_F_RX_IP_CKSUM_GOOD RTE_MBUF_F_RX_OUTER_L4_CKSUM_GOOD 

No Mark on packet !


With dpdk 22.11
...............

Tester Machine:
 scapy < port-42.scapy 

...>>> >>> >>> >>> >>> 
Sent 3 packets.

Result:
testpmd> port 0/queue 2: received 1 packets
  src=B8:CE:F6:83:B3:13 - dst=40:A6:B7:7D:43:90 - pool=mb_pool_0 - type=0x0800
- length=60 - nb_segs=1 - RSS hash=0xd302816a - RSS queue=0x2 - FDIR matched
ID=0x4 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_UDP  - sw ptype: L2_ETHER
L3_IPV4 L4_UDP  - l2_len=14 - l3_len=20 - l4_len=8 - Receive queue=0x2
  ol_flags: RTE_MBUF_F_RX_RSS_HASH RTE_MBUF_F_RX_FDIR
RTE_MBUF_F_RX_L4_CKSUM_GOOD RTE_MBUF_F_RX_IP_CKSUM_GOOD RTE_MBUF_F_RX_FDIR_ID
RTE_MBUF_F_RX_OUTER_L4_CKSUM_GOOD 
port 0/queue 2: received 1 packets
  src=B8:CE:F6:83:B3:13 - dst=40:A6:B7:7D:43:90 - pool=mb_pool_0 - type=0x0800
- length=60 - nb_segs=1 - RSS hash=0xd302816a - RSS queue=0x2 - FDIR matched
ID=0x4 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_UDP  - sw ptype: L2_ETHER
L3_IPV4 L4_UDP  - l2_len=14 - l3_len=20 - l4_len=8 - Receive queue=0x2
  ol_flags: RTE_MBUF_F_RX_RSS_HASH RTE_MBUF_F_RX_FDIR
RTE_MBUF_F_RX_L4_CKSUM_GOOD RTE_MBUF_F_RX_IP_CKSUM_GOOD RTE_MBUF_F_RX_FDIR_ID
RTE_MBUF_F_RX_OUTER_L4_CKSUM_GOOD 
port 0/queue 2: received 1 packets
  src=B8:CE:F6:83:B3:13 - dst=40:A6:B7:7D:43:90 - pool=mb_pool_0 - type=0x0800
- length=60 - nb_segs=1 - RSS hash=0xd302816a - RSS queue=0x2 - FDIR matched
ID=0x4 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_UDP  - sw ptype: L2_ETHER
L3_IPV4 L4_UDP  - l2_len=14 - l3_len=20 - l4_len=8 - Receive queue=0x2
  ol_flags: RTE_MBUF_F_RX_RSS_HASH RTE_MBUF_F_RX_FDIR
RTE_MBUF_F_RX_L4_CKSUM_GOOD RTE_MBUF_F_RX_IP_CKSUM_GOOD RTE_MBUF_F_RX_FDIR_ID
RTE_MBUF_F_RX_OUTER_L4_CKSUM_GOOD 

Packet is correctly marked.

It seems there is a regression between dpdk-22.11 and dpdk-23.03. Or at least,
a change of behavior of the rte flow API on ice pmd.

-- 
You are receiving this mail because:
You are the assignee for the bug.