Hello Matan and Slava,

Thanks for your quick response.

How about the following?

BR,
Hideyuki Yamashita
NTT TechnoCross

> Hello Matan and Slava,
> 
> Thanks for your quick response.
> 
> 1. What you were saying is correct.
>  When I create flow with dst mac 10:22:33:44:55:66 instead of
> 11:22:33:44:55:66, received packets are queued to specified queue.
> 
> Thanks for your advice!
> 
> Q1. What is the problem with broadcast/multicast address? 
> Q2. What is the bug number on Bugzilla of DPDK?
> Q3. What is the default behavior of unmatched packets?
> Discard packet or queue those to default queue(e.g. queue=0)?
> 
> When I tested packet distribution with vlan id, unmatched packets 
> looked discarded..
> I would like to know what is the default handling.
> 
> Thanks!
> 
> Best Regards,
> Hideyuki Yamashita
> NTT TechnoCross
> 
> 
> > Hi
> > 
> > This bit on in dst mac address = "01:00:00:00:00:00" means the packets is 
> > L2 multicast packet.
> > 
> > When you run Testpmd application the multicast configuration is forwarded 
> > to the device by default.
> > 
> > So, you have 2 rules:
> > The default which try to match on the above dst mac bit and to do RSS 
> > action for all the queues.
> > Your rule which try to match on dst mac 11:22:33:44:55:66 (the multicast 
> > bit is on) and more and to send it to queue 1.
> > 
> > So, your flow is sub flow of the default flow.
> > 
> > Since the current behavior in our driver is to put all the multicast rules 
> > in the same priority - the behavior for the case is unpredictable:
> > 1. you can get the packet twice for the 2 rules.
> > 2. you can get the packet onl for the default RSS action.
> > 3. you can get the packet only on queue 1 as in your rule.
> > 
> > Unfortunately, here, you got option 1 I think (you get the packet twice in 
> > your application).
> > 
> > This behavior in our driver to put the 2 rules in same behavior is in 
> > discussion by us - maybe it will be changed later.
> > 
> > To workaround the issue:
> > 1. do not configure the default rules (run with --flow-isolate-all in 
> > testpmd cmdline).
> > 2. do not configure 2 different multicast rules (even with different 
> > priorities).
> > 
> > Enjoy, let me know if you need more help....
> > 
> > Matan
> > 
> > From: Hideyuki Yamashita
> > > Hi Slava,
> > > 
> > > 
> > > Thanks for your response.
> > > 
> > > 1. Is the bug number is the follwoing?
> > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.
> > > dpdk.org%2Fshow_bug.cgi%3Fid%3D96&data=02%7C01%7Cmatan%40
> > > mellanox.com%7Ce10ce5ee0f8f4350c6a508d76bee3a97%7Ca652971c7d2e4d
> > > 9ba6a4d149256f461b%7C0%7C0%7C637096543244123210&sdata=V3V21
> > > gwJExHt7mkg0sAEwW%2FLTCIbJEkHznNtUCVkN%2BA%3D&reserved=0
> > > 
> > > 2.I've sent packets using scapy with the follwing script and I think it 
> > > is unicast
> > > ICMP.
> > > How did you thought the packets are broadcast/muticast?
> > > Note that I am not familiar with log of testpmd.
> > > 
> > > ----------------------------------------------------------------------------------------------
> > > from scapy.all import *
> > > 
> > > vlan_vid = 100
> > > vlan_prio = 0
> > > vlan_id = 0
> > > vlan_flg = True
> > > src_mac = "CC:CC:CC:CC:CC:CC"
> > > dst_mac = "11:22:33:44:55:66"
> > > dst_ip = "192.168.200.101"
> > > iface = "p7p1"
> > > pps = 5
> > > loop = 5
> > > 
> > > def icmp_send():
> > >     ls(Dot1Q)
> > >     if vlan_flg:
> > >         pkt = Ether(dst=dst_mac, src=src_mac)/Dot1Q(vlan=vlan_vid,
> > > prio=vlan_prio, id=vlan_id)/IP(dst=dst_ip)/ICMP()
> > >     else:
> > >         pkt = Ether(dst=dst_mac, src=src_mac)/IP(dst=dst_ip)/ICMP()
> > >     pkt.show()
> > >     sendpfast(pkt, iface=iface, pps=pps, loop=loop, file_cache=True)
> > > 
> > > icmp_send()
> > > -----------------------------------------------------------------------------
> > > 
> > > Thanks!
> > > 
> > > BR,
> > > Hideyuki Yamashita
> > > NTT TechnoCross
> > > 
> > > > Hi, Hideyuki
> > > >
> > > > The frame in your report is broadcast/multicast. Please, try unicast 
> > > > one.
> > > > For broadcast we have the ticket, currently issue is under 
> > > > investigation.
> > > > Anyway, thanks for reporting.
> > > >
> > > > With best regards, Slava
> > > >
> > > > > -----Original Message-----
> > > > > From: Hideyuki Yamashita <yamashita.hidey...@ntt-tx.co.jp>
> > > > > Sent: Thursday, November 14, 2019 7:02
> > > > > To: dev@dpdk.org
> > > > > Cc: Slava Ovsiienko <viachesl...@mellanox.com>
> > > > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow
> > > > > action on VLAN header
> > > > >
> > > > > Hello Slava,
> > > > >
> > > > > As I reported to you, creating flow was successful with Connect-X5.
> > > > > However when I sent packets to the NIC from outer side of the host,
> > > > > I have problem.
> > > > >
> > > > >
> > > > > [Case 1]
> > > > > Packet distribution on multi-queue based on dst MAC address.
> > > > >
> > > > > NIC config:
> > > > > 04:00.0 Mellanox Connect-X5
> > > > > 0.5.00.0 Intel XXV710
> > > > >
> > > > > testpmd startup param:
> > > > > sudo ./testpmd -c 1ffff -n 4 --socket-mem=1024,1024 --log-level=10 -w
> > > > > 04:00.0,dv_flow_en=1  -w 05:00.0    -- -i --rxq=16 --txq=16 
> > > > > --disable-rss --
> > > pkt-
> > > > > filter-mode=perfect
> > > > >
> > > > > flow command:
> > > > > testpmd> flow create 0 ingress pattern eth dst is 11:22:33:44:55:66
> > > > > testpmd> / end actions queue index 1 / end
> > > > > Flow rule #0 created
> > > > > testpmd> flow create 1 ingress pattern eth dst is 11:22:33:44:55:66
> > > > > testpmd> type mask 0xffff / end actions queue index 1 / end
> > > > > Flow rule #0 created
> > > > >
> > > > > Packet reception:(no VLAN tag)
> > > > > port 0/queue 0: received 1 packets
> > > > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > > > length=60
> > > > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN
> > > L4_NONFRAG  -
> > > > > sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Receive 
> > > > > queue=0x0
> > > > >   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD
> > > > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN port 1/queue 0: sent 1 packets
> > > > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > > > length=60
> > > > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN
> > > L4_NONFRAG  -
> > > > > sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Send queue=0x0
> > > > >   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD
> > > > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN
> > > > >
> > > > > port 1/queue 1: received 1 packets
> > > > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > > > length=60
> > > > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_ICMP  -
> > > sw
> > > > > ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Receive queue=0x1
> > > > >   ol_flags: PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD
> > > > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN port 0/queue 1: sent 1 packets
> > > > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > > > length=60
> > > > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_ICMP  -
> > > sw
> > > > > ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Send queue=0x1
> > > > >   ol_flags: PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD
> > > > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN
> > > > >
> > > > > Result:
> > > > > Matched packet queued to queue=0 port=0. Not queue=1, port=0.
> > > > >
> > > > > Expectation:
> > > > > When receiving packet which has dst MAC 11:22:33:44:55:66 should be
> > > > > received on queue=1 port=0.
> > > > >
> > > > > Question:
> > > > > Why matching packet is NOT enqueued into queue=1 on port=0?
> > > > >
> > > > >
> > > > > [Case 2]
> > > > > Packet distribution on multi-queue based on VLAN tag
> > > > >
> > > > > testpmd startup param:
> > > > > sudo ./testpmd -c 1ffff -n 4 --socket-mem=1024,1024 --log-level=10 -w
> > > > > 04:00.0,dv_flow_en=1  -w 05:00.0    -- -i --rxq=16 --txq=16 
> > > > > --disable-rss --
> > > pkt-
> > > > > filter-mode=perfect
> > > > >
> > > > > flow command:
> > > > > flow create 0 ingress group 1 pattern eth / vlan vid is 100 / end
> > > > > actions queue index 1 / of_pop_vlan / end flow create 0 ingress
> > > > > group 0 pattern eth / end actions jump group 1 / end
> > > > >
> > > > > Packet Reception: (VLAN100)
> > > > > port 0/queue 1: received 1 packets
> > > > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > > > length=56
> > > > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN
> > > L4_NONFRAG  -
> > > > > sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Receive 
> > > > > queue=0x1
> > > > >   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD
> > > > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN port 1/queue 1: sent 1 packets
> > > > >   src=CC:CC:CC:CC:CC:CC - dst=11:22:33:44:55:66 - type=0x0800 -
> > > > > length=56
> > > > > - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN
> > > L4_NONFRAG  -
> > > > > sw ptype: L2_ETHER L3_IPV4  - l2_len=14 - l3_len=20 - Send queue=0x1
> > > > >   ol_flags: PKT_RX_L4_CKSUM_UNKNOWN PKT_RX_IP_CKSUM_GOOD
> > > > > PKT_RX_OUTER_L4_CKSUM_UNKNOWN
> > > > >
> > > > > Result:
> > > > > Matched packetd queued to queue=1, port=0 Other packet(VLAN101
> > > > > packet) discarded.
> > > > >
> > > > > Expectation:
> > > > > Matched packet queued to queue =1, port=0 Non Matched packet
> > > queued
> > > > > to queue=0, port=0
> > > > >
> > > > > Question:
> > > > > Is above behavior collect?
> > > > > What is the default behavior of unmatchedd packets (queue to queue=0
> > > > > or discard packet)
> > > > >
> > > > > BR,
> > > > > Hideyuki Yamashita
> > > > > NTT TechnoCross
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > 
> > 
> 
> 


Reply via email to