* [dpdk-users] DPDK support for vlan id 0 @ 2021-05-12 15:40 Jagan P 2021-05-17 8:45 ` Muhammad Zain-ul-Abideen 0 siblings, 1 reply; 10+ messages in thread From: Jagan P @ 2021-05-12 15:40 UTC (permalink / raw) To: users Hi, We were trying to forward packets with vlan id as 0. But the packet is getting altered when we do so. The IP flag and the destination port fields are getting changed. We doubt if this is happening in DPDK because till the rte_eth_tx_burst API, the packet is proper. But the packet captured at the destination is altered. Could you please let us know if there is support in DPDK for forwarding packet with vlan id 0 or if we are missing something. Packet at rte_eth_tx_burst: dump mbuf at 0x1706dad00, iova=0x1706dad80, buf_len=2304 pkt_len=252, ol_flags=0xf0000000000181, nb_segs=1, port=0, vlan_tci=0, ptype=0x211 segment at 0x1706dad00, data=0x1706dae04, len=252, off=132, refcnt=1 Dump data at [0x1706dae04], len=200 00000000: 00 10 94 00 00 05 00 01 02 03 04 05 81 00 00 00 | ................ 00000010: 08 00 45 00 00 EA 00 02 00 00 3F 11 00 00 02 02 | ..E.......?..... 00000020: 02 02 05 05 05 02 62 A4 62 A3 00 D6 0E F2 00 00 | ......b.b....... 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000C0: 00 00 00 00 00 00 00 00 Packet captured at spirent(destination): 00 10 94 00 00 05 00 01 02 03 04 05 81 00 00 00 08 00 45 00 00 EA 00 02 6e fe 3F 11 00 00 02 02 02 02 05 05 05 02 62 A4 f5 f8 00 D6 0E F2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Thanks, Jagan P ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-users] DPDK support for vlan id 0 2021-05-12 15:40 [dpdk-users] DPDK support for vlan id 0 Jagan P @ 2021-05-17 8:45 ` Muhammad Zain-ul-Abideen 2021-05-17 11:45 ` Jagan P 0 siblings, 1 reply; 10+ messages in thread From: Muhammad Zain-ul-Abideen @ 2021-05-17 8:45 UTC (permalink / raw) To: Jagan P; +Cc: users Kindly tell us more about the setup and which dpdk you are using. and what is the packet life at sender and receiver. On Mon, May 17, 2021 at 1:01 PM Jagan P <jagan2.p@altran.com> wrote: > Hi, > We were trying to forward packets with vlan id as 0. But the packet is > getting altered when we do so. > The IP flag and the destination port fields are getting changed. We doubt > if this is happening in DPDK because till the rte_eth_tx_burst API, the > packet is proper. > But the packet captured at the destination is altered. > Could you please let us know if there is support in DPDK for forwarding > packet with vlan id 0 or if we are missing something. > > Packet at rte_eth_tx_burst: > dump mbuf at 0x1706dad00, iova=0x1706dad80, buf_len=2304 > pkt_len=252, ol_flags=0xf0000000000181, nb_segs=1, port=0, vlan_tci=0, > ptype=0x211 > segment at 0x1706dad00, data=0x1706dae04, len=252, off=132, refcnt=1 > Dump data at [0x1706dae04], len=200 > 00000000: 00 10 94 00 00 05 00 01 02 03 04 05 81 00 00 00 | > ................ > 00000010: 08 00 45 00 00 EA 00 02 00 00 3F 11 00 00 02 02 | > ..E.......?..... > 00000020: 02 02 05 05 05 02 62 A4 62 A3 00 D6 0E F2 00 00 | > ......b.b....... > 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 000000A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 000000B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 000000C0: 00 00 00 00 00 00 00 00 > > Packet captured at spirent(destination): > 00 10 94 00 00 05 00 01 02 03 04 05 81 00 00 00 > 08 00 45 00 00 EA 00 02 6e fe 3F 11 00 00 02 02 > 02 02 05 05 05 02 62 A4 f5 f8 00 D6 0E F2 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > Thanks, > Jagan P > > ===================================================== > Please refer to https://northamerica.altran.com/email-disclaimer > for important disclosures regarding this electronic communication. > ===================================================== > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-users] DPDK support for vlan id 0 2021-05-17 8:45 ` Muhammad Zain-ul-Abideen @ 2021-05-17 11:45 ` Jagan P 2021-05-17 12:02 ` Muhammad Zain-ul-Abideen 0 siblings, 1 reply; 10+ messages in thread From: Jagan P @ 2021-05-17 11:45 UTC (permalink / raw) To: Muhammad Zain-ul-Abideen; +Cc: users Hi Muhammad, We are using a single node connected to spirent Testcenter application(to send and receive traffic). The dpdk version used is 20.05 version. I have attached the packets captured in egress flow for vlan 0(vlan_0_pkt file) and with a valid vlan(vlan 12 and 18 – vlan_12_18_static file). We printed the packet in ixgbe_xmit_pkts API for vlan 0 and 12 and the captured dump is attached in “vlan_0 pkt_dump” file. We are sending IP packet with vlan tag along with UDP header. The packet flow will be as below. ingress port(rte_eth_rx_burst) => firewall =>routing=> nhop lookup =>ARP lookup => egress port pkt forwarding(rte_eth_tx_burst). We added packet dump before and after calling rte_eth_tx_burst API in our application. The dump looks good. So we added packet dump in ixgbe_xmit_pkts API as well to confirm whether the packet in proper in driver and the packet is proper here as well. We are not sure why the IP control flags and UDP dest port values are modified. Should we handle anything specifically for packets with vlan id 0 in rte_mbuf structure? Please share us your thoughts on this. Please let us know if any details are needed further. Thanks, Jagan P From: Muhammad Zain-ul-Abideen <zain2294@gmail.com> Sent: Monday, May 17, 2021 2:16 PM To: Jagan P <jagan2.p@altran.com> Cc: users@dpdk.org Subject: Re: [dpdk-users] DPDK support for vlan id 0 ** This mail has been sent from an external source ** Kindly tell us more about the setup and which dpdk you are using. and what is the packet life at sender and receiver. On Mon, May 17, 2021 at 1:01 PM Jagan P <jagan2.p@altran.com<mailto:jagan2.p@altran.com>> wrote: Hi, We were trying to forward packets with vlan id as 0. But the packet is getting altered when we do so. The IP flag and the destination port fields are getting changed. We doubt if this is happening in DPDK because till the rte_eth_tx_burst API, the packet is proper. But the packet captured at the destination is altered. Could you please let us know if there is support in DPDK for forwarding packet with vlan id 0 or if we are missing something. Packet at rte_eth_tx_burst: dump mbuf at 0x1706dad00, iova=0x1706dad80, buf_len=2304 pkt_len=252, ol_flags=0xf0000000000181, nb_segs=1, port=0, vlan_tci=0, ptype=0x211 segment at 0x1706dad00, data=0x1706dae04, len=252, off=132, refcnt=1 Dump data at [0x1706dae04], len=200 00000000: 00 10 94 00 00 05 00 01 02 03 04 05 81 00 00 00 | ................ 00000010: 08 00 45 00 00 EA 00 02 00 00 3F 11 00 00 02 02 | ..E.......?..... 00000020: 02 02 05 05 05 02 62 A4 62 A3 00 D6 0E F2 00 00 | ......b.b....... 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000C0: 00 00 00 00 00 00 00 00 Packet captured at spirent(destination): 00 10 94 00 00 05 00 01 02 03 04 05 81 00 00 00 08 00 45 00 00 EA 00 02 6e fe 3F 11 00 00 02 02 02 02 05 05 05 02 62 A4 f5 f8 00 D6 0E F2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Thanks, Jagan P ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-users] DPDK support for vlan id 0 2021-05-17 11:45 ` Jagan P @ 2021-05-17 12:02 ` Muhammad Zain-ul-Abideen 2021-05-17 15:24 ` Jagan P 0 siblings, 1 reply; 10+ messages in thread From: Muhammad Zain-ul-Abideen @ 2021-05-17 12:02 UTC (permalink / raw) To: Jagan P; +Cc: users Ok, it seems that there is some issue initializing the buffer and/or freeing it after use. It is not a DPDK issue not regenerated. 1) What are the trailing bytes at the end of UDP packets? 2) Are you reusing the buffer and/or initializing it correctly? 3) What NIC features are you using i.e. tx offloading? (As VLAN 12 has checksum calculated while VLAN 0 has not) Try forcing these bytes zero before and after sending the packet to see the impact On Mon, May 17, 2021 at 4:45 PM Jagan P <jagan2.p@altran.com> wrote: > Hi Muhammad, > > > > We are using a single node connected to spirent Testcenter application(to > send and receive traffic). > > The dpdk version used is 20.05 version. > > > > I have attached the packets captured in egress flow for vlan 0(vlan_0_pkt > file) and with a valid vlan(vlan 12 and 18 – vlan_12_18_static file). > > We printed the packet in *ixgbe_xmit_pkts* API for vlan 0 and 12 and the > captured dump is attached in “vlan_0 pkt_dump” file. > > > > We are sending IP packet with vlan tag along with UDP header. The packet > flow will be as below. > > ingress port(rte_eth_rx_burst) => firewall =>routing=> nhop lookup =>ARP > lookup => egress port pkt forwarding(rte_eth_tx_burst). > > > > We added packet dump before and after calling *rte_eth_tx_burst* API in > our application. The dump looks good. So we added packet dump in > *ixgbe_xmit_pkts* API as well to confirm whether the packet in proper in > driver and the packet is proper here as well. > > > > We are not sure why the IP control flags and UDP dest port values are > modified. Should we handle anything specifically for packets with vlan id 0 > in rte_mbuf structure? > > > > Please share us your thoughts on this. > > Please let us know if any details are needed further. > > > > Thanks, > > Jagan P > > > > *From:* Muhammad Zain-ul-Abideen <zain2294@gmail.com> > *Sent:* Monday, May 17, 2021 2:16 PM > *To:* Jagan P <jagan2.p@altran.com> > *Cc:* users@dpdk.org > *Subject:* Re: [dpdk-users] DPDK support for vlan id 0 > > > > ** This mail has been sent from an external source ** > > > > Kindly tell us more about the setup and which dpdk you are using. and what > is the packet life at sender and receiver. > > > > > > > > > > On Mon, May 17, 2021 at 1:01 PM Jagan P <jagan2.p@altran.com> wrote: > > Hi, > We were trying to forward packets with vlan id as 0. But the packet is > getting altered when we do so. > The IP flag and the destination port fields are getting changed. We doubt > if this is happening in DPDK because till the rte_eth_tx_burst API, the > packet is proper. > But the packet captured at the destination is altered. > Could you please let us know if there is support in DPDK for forwarding > packet with vlan id 0 or if we are missing something. > > Packet at rte_eth_tx_burst: > dump mbuf at 0x1706dad00, iova=0x1706dad80, buf_len=2304 > pkt_len=252, ol_flags=0xf0000000000181, nb_segs=1, port=0, vlan_tci=0, > ptype=0x211 > segment at 0x1706dad00, data=0x1706dae04, len=252, off=132, refcnt=1 > Dump data at [0x1706dae04], len=200 > 00000000: 00 10 94 00 00 05 00 01 02 03 04 05 81 00 00 00 | > ................ > 00000010: 08 00 45 00 00 EA 00 02 00 00 3F 11 00 00 02 02 | > ..E.......?..... > 00000020: 02 02 05 05 05 02 62 A4 62 A3 00 D6 0E F2 00 00 | > ......b.b....... > 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 000000A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 000000B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 000000C0: 00 00 00 00 00 00 00 00 > > Packet captured at spirent(destination): > 00 10 94 00 00 05 00 01 02 03 04 05 81 00 00 00 > 08 00 45 00 00 EA 00 02 6e fe 3F 11 00 00 02 02 > 02 02 05 05 05 02 62 A4 f5 f8 00 D6 0E F2 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > Thanks, > Jagan P > > ===================================================== > Please refer to https://northamerica.altran.com/email-disclaimer > for important disclosures regarding this electronic communication. > ===================================================== > > ===================================================== > Please refer to https://northamerica.altran.com/email-disclaimer > for important disclosures regarding this electronic communication. > ===================================================== > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-users] DPDK support for vlan id 0 2021-05-17 12:02 ` Muhammad Zain-ul-Abideen @ 2021-05-17 15:24 ` Jagan P 2021-05-17 15:28 ` Muhammad Zain-ul-Abideen 0 siblings, 1 reply; 10+ messages in thread From: Jagan P @ 2021-05-17 15:24 UTC (permalink / raw) To: Muhammad Zain-ul-Abideen; +Cc: users Please find the update below. 1) What are the trailing bytes at the end of UDP packets? >> Thank you will check it. 2) Are you reusing the buffer and/or initializing it correctly? >> Yes, we are re-using it. We are doing memset to zero of rte_mbuf’s buf_addr. 3) What NIC features are you using i.e. tx offloading? (As VLAN 12 has checksum calculated while VLAN 0 has not) >> Yes, we are doing tx offloading. From the packet capture in wireshark, it looks like, IPV4 control flags and checksum are swapped for vlan 0 alone. Try forcing these bytes zero before and after sending the packet to see the impact >> Sorry, I am not getting this point. Which bytes you are referring to? You mean not to do offloading and to set .offloads as zero in rte_eth_conf? Thanks, Jagan P From: Muhammad Zain-ul-Abideen <zain2294@gmail.com> Sent: Monday, May 17, 2021 5:32 PM To: Jagan P <jagan2.p@altran.com> Cc: users@dpdk.org Subject: Re: [dpdk-users] DPDK support for vlan id 0 ** This mail has been sent from an external source ** Ok, it seems that there is some issue initializing the buffer and/or freeing it after use. It is not a DPDK issue not regenerated. 1) What are the trailing bytes at the end of UDP packets? 2) Are you reusing the buffer and/or initializing it correctly? 3) What NIC features are you using i.e. tx offloading? (As VLAN 12 has checksum calculated while VLAN 0 has not) Try forcing these bytes zero before and after sending the packet to see the impact On Mon, May 17, 2021 at 4:45 PM Jagan P <jagan2.p@altran.com<mailto:jagan2.p@altran.com>> wrote: Hi Muhammad, We are using a single node connected to spirent Testcenter application(to send and receive traffic). The dpdk version used is 20.05 version. I have attached the packets captured in egress flow for vlan 0(vlan_0_pkt file) and with a valid vlan(vlan 12 and 18 – vlan_12_18_static file). We printed the packet in ixgbe_xmit_pkts API for vlan 0 and 12 and the captured dump is attached in “vlan_0 pkt_dump” file. We are sending IP packet with vlan tag along with UDP header. The packet flow will be as below. ingress port(rte_eth_rx_burst) => firewall =>routing=> nhop lookup =>ARP lookup => egress port pkt forwarding(rte_eth_tx_burst). We added packet dump before and after calling rte_eth_tx_burst API in our application. The dump looks good. So we added packet dump in ixgbe_xmit_pkts API as well to confirm whether the packet in proper in driver and the packet is proper here as well. We are not sure why the IP control flags and UDP dest port values are modified. Should we handle anything specifically for packets with vlan id 0 in rte_mbuf structure? Please share us your thoughts on this. Please let us know if any details are needed further. Thanks, Jagan P From: Muhammad Zain-ul-Abideen <zain2294@gmail.com<mailto:zain2294@gmail.com>> Sent: Monday, May 17, 2021 2:16 PM To: Jagan P <jagan2.p@altran.com<mailto:jagan2.p@altran.com>> Cc: users@dpdk.org<mailto:users@dpdk.org> Subject: Re: [dpdk-users] DPDK support for vlan id 0 ** This mail has been sent from an external source ** Kindly tell us more about the setup and which dpdk you are using. and what is the packet life at sender and receiver. On Mon, May 17, 2021 at 1:01 PM Jagan P <jagan2.p@altran.com<mailto:jagan2.p@altran.com>> wrote: Hi, We were trying to forward packets with vlan id as 0. But the packet is getting altered when we do so. The IP flag and the destination port fields are getting changed. We doubt if this is happening in DPDK because till the rte_eth_tx_burst API, the packet is proper. But the packet captured at the destination is altered. Could you please let us know if there is support in DPDK for forwarding packet with vlan id 0 or if we are missing something. Packet at rte_eth_tx_burst: dump mbuf at 0x1706dad00, iova=0x1706dad80, buf_len=2304 pkt_len=252, ol_flags=0xf0000000000181, nb_segs=1, port=0, vlan_tci=0, ptype=0x211 segment at 0x1706dad00, data=0x1706dae04, len=252, off=132, refcnt=1 Dump data at [0x1706dae04], len=200 00000000: 00 10 94 00 00 05 00 01 02 03 04 05 81 00 00 00 | ................ 00000010: 08 00 45 00 00 EA 00 02 00 00 3F 11 00 00 02 02 | ..E.......?..... 00000020: 02 02 05 05 05 02 62 A4 62 A3 00 D6 0E F2 00 00 | ......b.b....... 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000C0: 00 00 00 00 00 00 00 00 Packet captured at spirent(destination): 00 10 94 00 00 05 00 01 02 03 04 05 81 00 00 00 08 00 45 00 00 EA 00 02 6e fe 3F 11 00 00 02 02 02 02 05 05 05 02 62 A4 f5 f8 00 D6 0E F2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Thanks, Jagan P ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-users] DPDK support for vlan id 0 2021-05-17 15:24 ` Jagan P @ 2021-05-17 15:28 ` Muhammad Zain-ul-Abideen 2021-05-17 18:32 ` Jagan P 0 siblings, 1 reply; 10+ messages in thread From: Muhammad Zain-ul-Abideen @ 2021-05-17 15:28 UTC (permalink / raw) To: Jagan P; +Cc: users Remove all offloading at any side! U may set bytes of ipv4 flags to zero specially before sending out . And also remove any type of rx tx offloading.. and share the port config on dpdk On Mon, May 17, 2021, 8:24 PM Jagan P <jagan2.p@altran.com> wrote: > Please find the update below. > > 1) What are the trailing bytes at the end of UDP packets? > > >> Thank you will check it. > > > > 2) Are you reusing the buffer and/or initializing it correctly? > > >> Yes, we are re-using it. We are doing memset to zero of > rte_mbuf’s buf_addr. > > > > 3) What NIC features are you using i.e. tx offloading? (As VLAN 12 has > checksum calculated while VLAN 0 has not) > > >> Yes, we are doing tx offloading. From the packet > capture in wireshark, it looks like, IPV4 control flags and checksum are > swapped for vlan 0 alone. > > > > Try forcing these bytes zero before and after sending the packet to see > the impact > > >> Sorry, I am not getting this point. Which bytes you > are referring to? You mean not to do offloading and to set .offloads as > zero in rte_eth_conf? > > > > Thanks, > > Jagan P > > > > *From:* Muhammad Zain-ul-Abideen <zain2294@gmail.com> > *Sent:* Monday, May 17, 2021 5:32 PM > *To:* Jagan P <jagan2.p@altran.com> > *Cc:* users@dpdk.org > *Subject:* Re: [dpdk-users] DPDK support for vlan id 0 > > > > ** This mail has been sent from an external source ** > > > > Ok, it seems that there is some issue initializing the buffer and/or > freeing it after use. It is not a DPDK issue not regenerated. > > 1) What are the trailing bytes at the end of UDP packets? > > 2) Are you reusing the buffer and/or initializing it correctly? > > 3) What NIC features are you using i.e. tx offloading? (As VLAN 12 has > checksum calculated while VLAN 0 has not) > > Try forcing these bytes zero before and after sending the packet to see > the impact > > > > > > On Mon, May 17, 2021 at 4:45 PM Jagan P <jagan2.p@altran.com> wrote: > > Hi Muhammad, > > > > We are using a single node connected to spirent Testcenter application(to > send and receive traffic). > > The dpdk version used is 20.05 version. > > > > I have attached the packets captured in egress flow for vlan 0(vlan_0_pkt > file) and with a valid vlan(vlan 12 and 18 – vlan_12_18_static file). > > We printed the packet in *ixgbe_xmit_pkts* API for vlan 0 and 12 and the > captured dump is attached in “vlan_0 pkt_dump” file. > > > > We are sending IP packet with vlan tag along with UDP header. The packet > flow will be as below. > > ingress port(rte_eth_rx_burst) => firewall =>routing=> nhop lookup =>ARP > lookup => egress port pkt forwarding(rte_eth_tx_burst). > > > > We added packet dump before and after calling *rte_eth_tx_burst* API in > our application. The dump looks good. So we added packet dump in > *ixgbe_xmit_pkts* API as well to confirm whether the packet in proper in > driver and the packet is proper here as well. > > > > We are not sure why the IP control flags and UDP dest port values are > modified. Should we handle anything specifically for packets with vlan id 0 > in rte_mbuf structure? > > > > Please share us your thoughts on this. > > Please let us know if any details are needed further. > > > > Thanks, > > Jagan P > > > > *From:* Muhammad Zain-ul-Abideen <zain2294@gmail.com> > *Sent:* Monday, May 17, 2021 2:16 PM > *To:* Jagan P <jagan2.p@altran.com> > *Cc:* users@dpdk.org > *Subject:* Re: [dpdk-users] DPDK support for vlan id 0 > > > > ** This mail has been sent from an external source ** > > > > Kindly tell us more about the setup and which dpdk you are using. and what > is the packet life at sender and receiver. > > > > > > > > > > On Mon, May 17, 2021 at 1:01 PM Jagan P <jagan2.p@altran.com> wrote: > > Hi, > We were trying to forward packets with vlan id as 0. But the packet is > getting altered when we do so. > The IP flag and the destination port fields are getting changed. We doubt > if this is happening in DPDK because till the rte_eth_tx_burst API, the > packet is proper. > But the packet captured at the destination is altered. > Could you please let us know if there is support in DPDK for forwarding > packet with vlan id 0 or if we are missing something. > > Packet at rte_eth_tx_burst: > dump mbuf at 0x1706dad00, iova=0x1706dad80, buf_len=2304 > pkt_len=252, ol_flags=0xf0000000000181, nb_segs=1, port=0, vlan_tci=0, > ptype=0x211 > segment at 0x1706dad00, data=0x1706dae04, len=252, off=132, refcnt=1 > Dump data at [0x1706dae04], len=200 > 00000000: 00 10 94 00 00 05 00 01 02 03 04 05 81 00 00 00 | > ................ > 00000010: 08 00 45 00 00 EA 00 02 00 00 3F 11 00 00 02 02 | > ..E.......?..... > 00000020: 02 02 05 05 05 02 62 A4 62 A3 00 D6 0E F2 00 00 | > ......b.b....... > 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 000000A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 000000B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 000000C0: 00 00 00 00 00 00 00 00 > > Packet captured at spirent(destination): > 00 10 94 00 00 05 00 01 02 03 04 05 81 00 00 00 > 08 00 45 00 00 EA 00 02 6e fe 3F 11 00 00 02 02 > 02 02 05 05 05 02 62 A4 f5 f8 00 D6 0E F2 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > Thanks, > Jagan P > > ===================================================== > Please refer to https://northamerica.altran.com/email-disclaimer > for important disclosures regarding this electronic communication. > ===================================================== > > ===================================================== > Please refer to https://northamerica.altran.com/email-disclaimer > for important disclosures regarding this electronic communication. > ===================================================== > > ===================================================== > Please refer to https://northamerica.altran.com/email-disclaimer > for important disclosures regarding this electronic communication. > ===================================================== > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-users] DPDK support for vlan id 0 2021-05-17 15:28 ` Muhammad Zain-ul-Abideen @ 2021-05-17 18:32 ` Jagan P 2021-05-17 18:52 ` Muhammad Zain-ul-Abideen 0 siblings, 1 reply; 10+ messages in thread From: Jagan P @ 2021-05-17 18:32 UTC (permalink / raw) To: Muhammad Zain-ul-Abideen; +Cc: users Thanks a lot Muhammad for your inputs. We tried removing tx offloading in DPDK and now the packet is proper(IP control flag and UDP dest port values). Attaching the packets for reference. Should we change any flag settings in mbuf’s ol_flags for vlan id 0 since checksum offloading is proper for other vlans. Following flags are set for ol_flags to offload checksum. L3 checksum: PKT_TX_IPV4 and PKT_TX_IP_CKSUM Flags. L4 checksum: PKT_TX_IPV4, PKT_TX_IP_CKSUM and PKT_TX_UDP_CKSUM for UDP packets. With the above flags rte_ipv4_phdr_cksum API is triggered Port config: {link_speeds = 0, rxmode = {mq_mode = ETH_MQ_RX_NONE, max_rx_pkt_len = 9728, max_lro_pkt_size = 0, split_hdr_size = 0, offloads = 2, reserved_64s = { 0, 0}, reserved_ptrs = {0x0, 0x0}}, txmode = {mq_mode = ETH_MQ_TX_NONE, offloads = 2, pvid = 0, hw_vlan_reject_tagged = 0 '\000', hw_vlan_reject_untagged = 0 '\000', hw_vlan_insert_pvid = 0 '\000', reserved_64s = {0, 0}, reserved_ptrs = {0x0, 0x0}}, lpbk_mode = 0, rx_adv_conf = { rss_conf = {rss_key = 0x0, rss_key_len = 0 '\000', rss_hf = 0}, vmdq_dcb_conf = {nb_queue_pools = (unknown: 0), enable_default_pool = 0 '\000', default_pool = 0 '\000', nb_pool_maps = 0 '\000', pool_map = {{vlan_id = 0, pools = 0} <repeats 64 times>}, dcb_tc = "\000\000\000\000\000\000\000"}, dcb_rx_conf = {nb_tcs = (unknown: 0), dcb_tc = "\000\000\000\000\000\000\000"}, vmdq_rx_conf = {nb_queue_pools = (unknown: 0), enable_default_pool = 0 '\000', default_pool = 0 '\000', enable_loop_back = 0 '\000', nb_pool_maps = 0 '\000', rx_mode = 0, pool_map = {{vlan_id = 0, pools = 0} <repeats 64 times>}}}, tx_adv_conf = {vmdq_dcb_tx_conf = {nb_queue_pools = (unknown: 0), dcb_tc = "\000\000\000\000\000\000\000"}, dcb_tx_conf = {nb_tcs = (unknown: 0), dcb_tc = "\000\000\000\000\000\000\000"}, vmdq_tx_conf = {nb_queue_pools = (unknown: 0)}}, dcb_capability_en = 0, fdir_conf = {mode = RTE_FDIR_MODE_NONE, pballoc = RTE_FDIR_PBALLOC_64K, status = RTE_FDIR_NO_REPORT_STATUS, drop_queue = 0 '\000', mask = { vlan_tci_mask = 0, ipv4_mask = {src_ip = 0, dst_ip = 0, tos = 0 '\000', ttl = 0 '\000', proto = 0 '\000'}, ipv6_mask = {src_ip = {0, 0, 0, 0}, dst_ip = {0, 0, 0, 0}, tc = 0 '\000', proto = 0 '\000', hop_limits = 0 '\000'}, src_port_mask = 0, dst_port_mask = 0, mac_addr_byte_mask = 0 '\000', tunnel_id_mask = 0, tunnel_type_mask = 0 '\000'}, flex_conf = {nb_payloads = 0, nb_flexmasks = 0, flex_set = {{ type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 times>}}, {type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 times>}}, { type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 times>}}, {type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 times>}}, { type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 times>}}, {type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 times>}}, { type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 times>}}, {type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 times>}}}, flex_mask = {{flow_type = 0, mask = '\000' <repeats 15 times>} <repeats 24 times>}}}, intr_conf = {lsc = 0, rxq = 0, rmv = 0}} Thanks, Jagan P From: Muhammad Zain-ul-Abideen <zain2294@gmail.com> Sent: Monday, May 17, 2021 8:59 PM To: Jagan P <jagan2.p@altran.com> Cc: users <users@dpdk.org> Subject: Re: [dpdk-users] DPDK support for vlan id 0 ** This mail has been sent from an external source ** Remove all offloading at any side! U may set bytes of ipv4 flags to zero specially before sending out . And also remove any type of rx tx offloading.. and share the port config on dpdk On Mon, May 17, 2021, 8:24 PM Jagan P <jagan2.p@altran.com<mailto:jagan2.p@altran.com>> wrote: Please find the update below. 1) What are the trailing bytes at the end of UDP packets? >> Thank you will check it. 2) Are you reusing the buffer and/or initializing it correctly? >> Yes, we are re-using it. We are doing memset to zero of rte_mbuf’s buf_addr. 3) What NIC features are you using i.e. tx offloading? (As VLAN 12 has checksum calculated while VLAN 0 has not) >> Yes, we are doing tx offloading. From the packet capture in wireshark, it looks like, IPV4 control flags and checksum are swapped for vlan 0 alone. Try forcing these bytes zero before and after sending the packet to see the impact >> Sorry, I am not getting this point. Which bytes you are referring to? You mean not to do offloading and to set .offloads as zero in rte_eth_conf? Thanks, Jagan P From: Muhammad Zain-ul-Abideen <zain2294@gmail.com<mailto:zain2294@gmail.com>> Sent: Monday, May 17, 2021 5:32 PM To: Jagan P <jagan2.p@altran.com<mailto:jagan2.p@altran.com>> Cc: users@dpdk.org<mailto:users@dpdk.org> Subject: Re: [dpdk-users] DPDK support for vlan id 0 ** This mail has been sent from an external source ** Ok, it seems that there is some issue initializing the buffer and/or freeing it after use. It is not a DPDK issue not regenerated. 1) What are the trailing bytes at the end of UDP packets? 2) Are you reusing the buffer and/or initializing it correctly? 3) What NIC features are you using i.e. tx offloading? (As VLAN 12 has checksum calculated while VLAN 0 has not) Try forcing these bytes zero before and after sending the packet to see the impact On Mon, May 17, 2021 at 4:45 PM Jagan P <jagan2.p@altran.com<mailto:jagan2.p@altran.com>> wrote: Hi Muhammad, We are using a single node connected to spirent Testcenter application(to send and receive traffic). The dpdk version used is 20.05 version. I have attached the packets captured in egress flow for vlan 0(vlan_0_pkt file) and with a valid vlan(vlan 12 and 18 – vlan_12_18_static file). We printed the packet in ixgbe_xmit_pkts API for vlan 0 and 12 and the captured dump is attached in “vlan_0 pkt_dump” file. We are sending IP packet with vlan tag along with UDP header. The packet flow will be as below. ingress port(rte_eth_rx_burst) => firewall =>routing=> nhop lookup =>ARP lookup => egress port pkt forwarding(rte_eth_tx_burst). We added packet dump before and after calling rte_eth_tx_burst API in our application. The dump looks good. So we added packet dump in ixgbe_xmit_pkts API as well to confirm whether the packet in proper in driver and the packet is proper here as well. We are not sure why the IP control flags and UDP dest port values are modified. Should we handle anything specifically for packets with vlan id 0 in rte_mbuf structure? Please share us your thoughts on this. Please let us know if any details are needed further. Thanks, Jagan P From: Muhammad Zain-ul-Abideen <zain2294@gmail.com<mailto:zain2294@gmail.com>> Sent: Monday, May 17, 2021 2:16 PM To: Jagan P <jagan2.p@altran.com<mailto:jagan2.p@altran.com>> Cc: users@dpdk.org<mailto:users@dpdk.org> Subject: Re: [dpdk-users] DPDK support for vlan id 0 ** This mail has been sent from an external source ** Kindly tell us more about the setup and which dpdk you are using. and what is the packet life at sender and receiver. On Mon, May 17, 2021 at 1:01 PM Jagan P <jagan2.p@altran.com<mailto:jagan2.p@altran.com>> wrote: Hi, We were trying to forward packets with vlan id as 0. But the packet is getting altered when we do so. The IP flag and the destination port fields are getting changed. We doubt if this is happening in DPDK because till the rte_eth_tx_burst API, the packet is proper. But the packet captured at the destination is altered. Could you please let us know if there is support in DPDK for forwarding packet with vlan id 0 or if we are missing something. Packet at rte_eth_tx_burst: dump mbuf at 0x1706dad00, iova=0x1706dad80, buf_len=2304 pkt_len=252, ol_flags=0xf0000000000181, nb_segs=1, port=0, vlan_tci=0, ptype=0x211 segment at 0x1706dad00, data=0x1706dae04, len=252, off=132, refcnt=1 Dump data at [0x1706dae04], len=200 00000000: 00 10 94 00 00 05 00 01 02 03 04 05 81 00 00 00 | ................ 00000010: 08 00 45 00 00 EA 00 02 00 00 3F 11 00 00 02 02 | ..E.......?..... 00000020: 02 02 05 05 05 02 62 A4 62 A3 00 D6 0E F2 00 00 | ......b.b....... 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000C0: 00 00 00 00 00 00 00 00 Packet captured at spirent(destination): 00 10 94 00 00 05 00 01 02 03 04 05 81 00 00 00 08 00 45 00 00 EA 00 02 6e fe 3F 11 00 00 02 02 02 02 05 05 05 02 62 A4 f5 f8 00 D6 0E F2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Thanks, Jagan P ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-users] DPDK support for vlan id 0 2021-05-17 18:32 ` Jagan P @ 2021-05-17 18:52 ` Muhammad Zain-ul-Abideen 2021-05-18 6:47 ` Jagan P 0 siblings, 1 reply; 10+ messages in thread From: Muhammad Zain-ul-Abideen @ 2021-05-17 18:52 UTC (permalink / raw) To: Jagan P; +Cc: users Good to hear. What NICs are you using? Now need to understand the NIC limitations if any. Yes, for vlan0 don't set checksum calculation offload and insert via software but u won't get line rate for vlan0.. need to toy around a bit . First thing first do you need checksum validation at reciever? On Mon, May 17, 2021, 11:32 PM Jagan P <jagan2.p@altran.com> wrote: > Thanks a lot Muhammad for your inputs. > > > > We tried removing tx offloading in DPDK and now the packet is proper(IP > control flag and UDP dest port values). > > Attaching the packets for reference. > > > > Should we change any flag settings in mbuf’s ol_flags for vlan id 0 since > checksum offloading is proper for other vlans. > > > > Following flags are set for ol_flags to offload checksum. > > *L3 checksum:* > > PKT_TX_IPV4 and PKT_TX_IP_CKSUM Flags. > > > > *L4 checksum:* > > PKT_TX_IPV4, PKT_TX_IP_CKSUM and PKT_TX_UDP_CKSUM for UDP packets. > > > > With the above flags rte_ipv4_phdr_cksum API is triggered > > > > *Port config:* > > {link_speeds = 0, rxmode = {mq_mode = ETH_MQ_RX_NONE, max_rx_pkt_len = > 9728, max_lro_pkt_size = 0, split_hdr_size = 0, offloads = 2, reserved_64s > = { > > 0, 0}, reserved_ptrs = {0x0, 0x0}}, txmode = {mq_mode = > ETH_MQ_TX_NONE, offloads = 2, pvid = 0, hw_vlan_reject_tagged = 0 '\000', > > hw_vlan_reject_untagged = 0 '\000', hw_vlan_insert_pvid = 0 '\000', > reserved_64s = {0, 0}, reserved_ptrs = {0x0, 0x0}}, lpbk_mode = 0, > rx_adv_conf = { > > rss_conf = {rss_key = 0x0, rss_key_len = 0 '\000', rss_hf = 0}, > vmdq_dcb_conf = {nb_queue_pools = (unknown: 0), enable_default_pool = 0 > '\000', > > default_pool = 0 '\000', nb_pool_maps = 0 '\000', pool_map = > {{vlan_id = 0, pools = 0} <repeats 64 times>}, dcb_tc = > "\000\000\000\000\000\000\000"}, > > dcb_rx_conf = {nb_tcs = (unknown: 0), dcb_tc = > "\000\000\000\000\000\000\000"}, vmdq_rx_conf = {nb_queue_pools = (unknown: > 0), > > enable_default_pool = 0 '\000', default_pool = 0 '\000', > enable_loop_back = 0 '\000', nb_pool_maps = 0 '\000', rx_mode = 0, pool_map > = {{vlan_id = 0, > > pools = 0} <repeats 64 times>}}}, tx_adv_conf = > {vmdq_dcb_tx_conf = {nb_queue_pools = (unknown: 0), dcb_tc = > "\000\000\000\000\000\000\000"}, > > dcb_tx_conf = {nb_tcs = (unknown: 0), dcb_tc = > "\000\000\000\000\000\000\000"}, vmdq_tx_conf = {nb_queue_pools = (unknown: > 0)}}, dcb_capability_en = 0, > > fdir_conf = {mode = RTE_FDIR_MODE_NONE, pballoc = RTE_FDIR_PBALLOC_64K, > status = RTE_FDIR_NO_REPORT_STATUS, drop_queue = 0 '\000', mask = { > > vlan_tci_mask = 0, ipv4_mask = {src_ip = 0, dst_ip = 0, tos = 0 > '\000', ttl = 0 '\000', proto = 0 '\000'}, ipv6_mask = {src_ip = {0, 0, 0, > 0}, > > dst_ip = {0, 0, 0, 0}, tc = 0 '\000', proto = 0 '\000', hop_limits > = 0 '\000'}, src_port_mask = 0, dst_port_mask = 0, > > mac_addr_byte_mask = 0 '\000', tunnel_id_mask = 0, tunnel_type_mask > = 0 '\000'}, flex_conf = {nb_payloads = 0, nb_flexmasks = 0, flex_set = {{ > > type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 > times>}}, {type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 > times>}}, { > > type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 > times>}}, {type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 > times>}}, { > > type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 > times>}}, {type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 > times>}}, { > > type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 > times>}}, {type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 > times>}}}, > > flex_mask = {{flow_type = 0, mask = '\000' <repeats 15 times>} > <repeats 24 times>}}}, intr_conf = {lsc = 0, rxq = 0, rmv = 0}} > > > > Thanks, > > Jagan P > > > > > > *From:* Muhammad Zain-ul-Abideen <zain2294@gmail.com> > *Sent:* Monday, May 17, 2021 8:59 PM > *To:* Jagan P <jagan2.p@altran.com> > *Cc:* users <users@dpdk.org> > *Subject:* Re: [dpdk-users] DPDK support for vlan id 0 > > > > ** This mail has been sent from an external source ** > > > > Remove all offloading at any side! > > U may set bytes of ipv4 flags to zero specially before sending out . And > also remove any type of rx tx offloading.. and share the port config on dpdk > > > > On Mon, May 17, 2021, 8:24 PM Jagan P <jagan2.p@altran.com> wrote: > > Please find the update below. > > 1) What are the trailing bytes at the end of UDP packets? > > >> Thank you will check it. > > > > 2) Are you reusing the buffer and/or initializing it correctly? > > >> Yes, we are re-using it. We are doing memset to zero of > rte_mbuf’s buf_addr. > > > > 3) What NIC features are you using i.e. tx offloading? (As VLAN 12 has > checksum calculated while VLAN 0 has not) > > >> Yes, we are doing tx offloading. From the packet > capture in wireshark, it looks like, IPV4 control flags and checksum are > swapped for vlan 0 alone. > > > > Try forcing these bytes zero before and after sending the packet to see > the impact > > >> Sorry, I am not getting this point. Which bytes you > are referring to? You mean not to do offloading and to set .offloads as > zero in rte_eth_conf? > > > > Thanks, > > Jagan P > > > > *From:* Muhammad Zain-ul-Abideen <zain2294@gmail.com> > *Sent:* Monday, May 17, 2021 5:32 PM > *To:* Jagan P <jagan2.p@altran.com> > *Cc:* users@dpdk.org > *Subject:* Re: [dpdk-users] DPDK support for vlan id 0 > > > > ** This mail has been sent from an external source ** > > > > Ok, it seems that there is some issue initializing the buffer and/or > freeing it after use. It is not a DPDK issue not regenerated. > > 1) What are the trailing bytes at the end of UDP packets? > > 2) Are you reusing the buffer and/or initializing it correctly? > > 3) What NIC features are you using i.e. tx offloading? (As VLAN 12 has > checksum calculated while VLAN 0 has not) > > Try forcing these bytes zero before and after sending the packet to see > the impact > > > > > > On Mon, May 17, 2021 at 4:45 PM Jagan P <jagan2.p@altran.com> wrote: > > Hi Muhammad, > > > > We are using a single node connected to spirent Testcenter application(to > send and receive traffic). > > The dpdk version used is 20.05 version. > > > > I have attached the packets captured in egress flow for vlan 0(vlan_0_pkt > file) and with a valid vlan(vlan 12 and 18 – vlan_12_18_static file). > > We printed the packet in *ixgbe_xmit_pkts* API for vlan 0 and 12 and the > captured dump is attached in “vlan_0 pkt_dump” file. > > > > We are sending IP packet with vlan tag along with UDP header. The packet > flow will be as below. > > ingress port(rte_eth_rx_burst) => firewall =>routing=> nhop lookup =>ARP > lookup => egress port pkt forwarding(rte_eth_tx_burst). > > > > We added packet dump before and after calling *rte_eth_tx_burst* API in > our application. The dump looks good. So we added packet dump in > *ixgbe_xmit_pkts* API as well to confirm whether the packet in proper in > driver and the packet is proper here as well. > > > > We are not sure why the IP control flags and UDP dest port values are > modified. Should we handle anything specifically for packets with vlan id 0 > in rte_mbuf structure? > > > > Please share us your thoughts on this. > > Please let us know if any details are needed further. > > > > Thanks, > > Jagan P > > > > *From:* Muhammad Zain-ul-Abideen <zain2294@gmail.com> > *Sent:* Monday, May 17, 2021 2:16 PM > *To:* Jagan P <jagan2.p@altran.com> > *Cc:* users@dpdk.org > *Subject:* Re: [dpdk-users] DPDK support for vlan id 0 > > > > ** This mail has been sent from an external source ** > > > > Kindly tell us more about the setup and which dpdk you are using. and what > is the packet life at sender and receiver. > > > > > > > > > > On Mon, May 17, 2021 at 1:01 PM Jagan P <jagan2.p@altran.com> wrote: > > Hi, > We were trying to forward packets with vlan id as 0. But the packet is > getting altered when we do so. > The IP flag and the destination port fields are getting changed. We doubt > if this is happening in DPDK because till the rte_eth_tx_burst API, the > packet is proper. > But the packet captured at the destination is altered. > Could you please let us know if there is support in DPDK for forwarding > packet with vlan id 0 or if we are missing something. > > Packet at rte_eth_tx_burst: > dump mbuf at 0x1706dad00, iova=0x1706dad80, buf_len=2304 > pkt_len=252, ol_flags=0xf0000000000181, nb_segs=1, port=0, vlan_tci=0, > ptype=0x211 > segment at 0x1706dad00, data=0x1706dae04, len=252, off=132, refcnt=1 > Dump data at [0x1706dae04], len=200 > 00000000: 00 10 94 00 00 05 00 01 02 03 04 05 81 00 00 00 | > ................ > 00000010: 08 00 45 00 00 EA 00 02 00 00 3F 11 00 00 02 02 | > ..E.......?..... > 00000020: 02 02 05 05 05 02 62 A4 62 A3 00 D6 0E F2 00 00 | > ......b.b....... > 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 000000A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 000000B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 000000C0: 00 00 00 00 00 00 00 00 > > Packet captured at spirent(destination): > 00 10 94 00 00 05 00 01 02 03 04 05 81 00 00 00 > 08 00 45 00 00 EA 00 02 6e fe 3F 11 00 00 02 02 > 02 02 05 05 05 02 62 A4 f5 f8 00 D6 0E F2 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > Thanks, > Jagan P > > ===================================================== > Please refer to https://northamerica.altran.com/email-disclaimer > for important disclosures regarding this electronic communication. > ===================================================== > > ===================================================== > Please refer to https://northamerica.altran.com/email-disclaimer > for important disclosures regarding this electronic communication. > ===================================================== > > ===================================================== > Please refer to https://northamerica.altran.com/email-disclaimer > for important disclosures regarding this electronic communication. > ===================================================== > > ===================================================== > Please refer to https://northamerica.altran.com/email-disclaimer > for important disclosures regarding this electronic communication. > ===================================================== > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-users] DPDK support for vlan id 0 2021-05-17 18:52 ` Muhammad Zain-ul-Abideen @ 2021-05-18 6:47 ` Jagan P 2021-05-18 8:46 ` Muhammad Zain-ul-Abideen 0 siblings, 1 reply; 10+ messages in thread From: Jagan P @ 2021-05-18 6:47 UTC (permalink / raw) To: Muhammad Zain-ul-Abideen; +Cc: users Please find the update below. What NICs are you using? Now need to understand the NIC limitations if any. >> The NIC we are using is “82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb". Yes, for vlan0 don't set checksum calculation offload and insert via software but u won't get line rate for vlan0 >> Does this mean there is no support for vlan 0 in DPDK. Can this be achieved in DPDK as there will be a compromise in performance when done in software. First thing first do you need checksum validation at reciever? >> Actually we may not require checksum validation at receiver end. Checksum on transmission alone is fine. But could you please explain the reason behind this ask Thanks, Jagan P From: Muhammad Zain-ul-Abideen <zain2294@gmail.com> Sent: Tuesday, May 18, 2021 12:23 AM To: Jagan P <jagan2.p@altran.com> Cc: users <users@dpdk.org> Subject: Re: [dpdk-users] DPDK support for vlan id 0 ** This mail has been sent from an external source ** Good to hear. What NICs are you using? Now need to understand the NIC limitations if any. Yes, for vlan0 don't set checksum calculation offload and insert via software but u won't get line rate for vlan0.. need to toy around a bit . First thing first do you need checksum validation at reciever? On Mon, May 17, 2021, 11:32 PM Jagan P <jagan2.p@altran.com<mailto:jagan2.p@altran.com>> wrote: Thanks a lot Muhammad for your inputs. We tried removing tx offloading in DPDK and now the packet is proper(IP control flag and UDP dest port values). Attaching the packets for reference. Should we change any flag settings in mbuf’s ol_flags for vlan id 0 since checksum offloading is proper for other vlans. Following flags are set for ol_flags to offload checksum. L3 checksum: PKT_TX_IPV4 and PKT_TX_IP_CKSUM Flags. L4 checksum: PKT_TX_IPV4, PKT_TX_IP_CKSUM and PKT_TX_UDP_CKSUM for UDP packets. With the above flags rte_ipv4_phdr_cksum API is triggered Port config: {link_speeds = 0, rxmode = {mq_mode = ETH_MQ_RX_NONE, max_rx_pkt_len = 9728, max_lro_pkt_size = 0, split_hdr_size = 0, offloads = 2, reserved_64s = { 0, 0}, reserved_ptrs = {0x0, 0x0}}, txmode = {mq_mode = ETH_MQ_TX_NONE, offloads = 2, pvid = 0, hw_vlan_reject_tagged = 0 '\000', hw_vlan_reject_untagged = 0 '\000', hw_vlan_insert_pvid = 0 '\000', reserved_64s = {0, 0}, reserved_ptrs = {0x0, 0x0}}, lpbk_mode = 0, rx_adv_conf = { rss_conf = {rss_key = 0x0, rss_key_len = 0 '\000', rss_hf = 0}, vmdq_dcb_conf = {nb_queue_pools = (unknown: 0), enable_default_pool = 0 '\000', default_pool = 0 '\000', nb_pool_maps = 0 '\000', pool_map = {{vlan_id = 0, pools = 0} <repeats 64 times>}, dcb_tc = "\000\000\000\000\000\000\000"}, dcb_rx_conf = {nb_tcs = (unknown: 0), dcb_tc = "\000\000\000\000\000\000\000"}, vmdq_rx_conf = {nb_queue_pools = (unknown: 0), enable_default_pool = 0 '\000', default_pool = 0 '\000', enable_loop_back = 0 '\000', nb_pool_maps = 0 '\000', rx_mode = 0, pool_map = {{vlan_id = 0, pools = 0} <repeats 64 times>}}}, tx_adv_conf = {vmdq_dcb_tx_conf = {nb_queue_pools = (unknown: 0), dcb_tc = "\000\000\000\000\000\000\000"}, dcb_tx_conf = {nb_tcs = (unknown: 0), dcb_tc = "\000\000\000\000\000\000\000"}, vmdq_tx_conf = {nb_queue_pools = (unknown: 0)}}, dcb_capability_en = 0, fdir_conf = {mode = RTE_FDIR_MODE_NONE, pballoc = RTE_FDIR_PBALLOC_64K, status = RTE_FDIR_NO_REPORT_STATUS, drop_queue = 0 '\000', mask = { vlan_tci_mask = 0, ipv4_mask = {src_ip = 0, dst_ip = 0, tos = 0 '\000', ttl = 0 '\000', proto = 0 '\000'}, ipv6_mask = {src_ip = {0, 0, 0, 0}, dst_ip = {0, 0, 0, 0}, tc = 0 '\000', proto = 0 '\000', hop_limits = 0 '\000'}, src_port_mask = 0, dst_port_mask = 0, mac_addr_byte_mask = 0 '\000', tunnel_id_mask = 0, tunnel_type_mask = 0 '\000'}, flex_conf = {nb_payloads = 0, nb_flexmasks = 0, flex_set = {{ type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 times>}}, {type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 times>}}, { type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 times>}}, {type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 times>}}, { type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 times>}}, {type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 times>}}, { type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 times>}}, {type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 times>}}}, flex_mask = {{flow_type = 0, mask = '\000' <repeats 15 times>} <repeats 24 times>}}}, intr_conf = {lsc = 0, rxq = 0, rmv = 0}} Thanks, Jagan P From: Muhammad Zain-ul-Abideen <zain2294@gmail.com<mailto:zain2294@gmail.com>> Sent: Monday, May 17, 2021 8:59 PM To: Jagan P <jagan2.p@altran.com<mailto:jagan2.p@altran.com>> Cc: users <users@dpdk.org<mailto:users@dpdk.org>> Subject: Re: [dpdk-users] DPDK support for vlan id 0 ** This mail has been sent from an external source ** Remove all offloading at any side! U may set bytes of ipv4 flags to zero specially before sending out . And also remove any type of rx tx offloading.. and share the port config on dpdk On Mon, May 17, 2021, 8:24 PM Jagan P <jagan2.p@altran.com<mailto:jagan2.p@altran.com>> wrote: Please find the update below. 1) What are the trailing bytes at the end of UDP packets? >> Thank you will check it. 2) Are you reusing the buffer and/or initializing it correctly? >> Yes, we are re-using it. We are doing memset to zero of rte_mbuf’s buf_addr. 3) What NIC features are you using i.e. tx offloading? (As VLAN 12 has checksum calculated while VLAN 0 has not) >> Yes, we are doing tx offloading. From the packet capture in wireshark, it looks like, IPV4 control flags and checksum are swapped for vlan 0 alone. Try forcing these bytes zero before and after sending the packet to see the impact >> Sorry, I am not getting this point. Which bytes you are referring to? You mean not to do offloading and to set .offloads as zero in rte_eth_conf? Thanks, Jagan P From: Muhammad Zain-ul-Abideen <zain2294@gmail.com<mailto:zain2294@gmail.com>> Sent: Monday, May 17, 2021 5:32 PM To: Jagan P <jagan2.p@altran.com<mailto:jagan2.p@altran.com>> Cc: users@dpdk.org<mailto:users@dpdk.org> Subject: Re: [dpdk-users] DPDK support for vlan id 0 ** This mail has been sent from an external source ** Ok, it seems that there is some issue initializing the buffer and/or freeing it after use. It is not a DPDK issue not regenerated. 1) What are the trailing bytes at the end of UDP packets? 2) Are you reusing the buffer and/or initializing it correctly? 3) What NIC features are you using i.e. tx offloading? (As VLAN 12 has checksum calculated while VLAN 0 has not) Try forcing these bytes zero before and after sending the packet to see the impact On Mon, May 17, 2021 at 4:45 PM Jagan P <jagan2.p@altran.com<mailto:jagan2.p@altran.com>> wrote: Hi Muhammad, We are using a single node connected to spirent Testcenter application(to send and receive traffic). The dpdk version used is 20.05 version. I have attached the packets captured in egress flow for vlan 0(vlan_0_pkt file) and with a valid vlan(vlan 12 and 18 – vlan_12_18_static file). We printed the packet in ixgbe_xmit_pkts API for vlan 0 and 12 and the captured dump is attached in “vlan_0 pkt_dump” file. We are sending IP packet with vlan tag along with UDP header. The packet flow will be as below. ingress port(rte_eth_rx_burst) => firewall =>routing=> nhop lookup =>ARP lookup => egress port pkt forwarding(rte_eth_tx_burst). We added packet dump before and after calling rte_eth_tx_burst API in our application. The dump looks good. So we added packet dump in ixgbe_xmit_pkts API as well to confirm whether the packet in proper in driver and the packet is proper here as well. We are not sure why the IP control flags and UDP dest port values are modified. Should we handle anything specifically for packets with vlan id 0 in rte_mbuf structure? Please share us your thoughts on this. Please let us know if any details are needed further. Thanks, Jagan P From: Muhammad Zain-ul-Abideen <zain2294@gmail.com<mailto:zain2294@gmail.com>> Sent: Monday, May 17, 2021 2:16 PM To: Jagan P <jagan2.p@altran.com<mailto:jagan2.p@altran.com>> Cc: users@dpdk.org<mailto:users@dpdk.org> Subject: Re: [dpdk-users] DPDK support for vlan id 0 ** This mail has been sent from an external source ** Kindly tell us more about the setup and which dpdk you are using. and what is the packet life at sender and receiver. On Mon, May 17, 2021 at 1:01 PM Jagan P <jagan2.p@altran.com<mailto:jagan2.p@altran.com>> wrote: Hi, We were trying to forward packets with vlan id as 0. But the packet is getting altered when we do so. The IP flag and the destination port fields are getting changed. We doubt if this is happening in DPDK because till the rte_eth_tx_burst API, the packet is proper. But the packet captured at the destination is altered. Could you please let us know if there is support in DPDK for forwarding packet with vlan id 0 or if we are missing something. Packet at rte_eth_tx_burst: dump mbuf at 0x1706dad00, iova=0x1706dad80, buf_len=2304 pkt_len=252, ol_flags=0xf0000000000181, nb_segs=1, port=0, vlan_tci=0, ptype=0x211 segment at 0x1706dad00, data=0x1706dae04, len=252, off=132, refcnt=1 Dump data at [0x1706dae04], len=200 00000000: 00 10 94 00 00 05 00 01 02 03 04 05 81 00 00 00 | ................ 00000010: 08 00 45 00 00 EA 00 02 00 00 3F 11 00 00 02 02 | ..E.......?..... 00000020: 02 02 05 05 05 02 62 A4 62 A3 00 D6 0E F2 00 00 | ......b.b....... 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ 000000C0: 00 00 00 00 00 00 00 00 Packet captured at spirent(destination): 00 10 94 00 00 05 00 01 02 03 04 05 81 00 00 00 08 00 45 00 00 EA 00 02 6e fe 3F 11 00 00 02 02 02 02 05 05 05 02 62 A4 f5 f8 00 D6 0E F2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Thanks, Jagan P ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== ===================================================== Please refer to https://northamerica.altran.com/email-disclaimer for important disclosures regarding this electronic communication. ===================================================== ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-users] DPDK support for vlan id 0 2021-05-18 6:47 ` Jagan P @ 2021-05-18 8:46 ` Muhammad Zain-ul-Abideen 0 siblings, 0 replies; 10+ messages in thread From: Muhammad Zain-ul-Abideen @ 2021-05-18 8:46 UTC (permalink / raw) To: Jagan P; +Cc: users Irrespective of DPDK, this is a NIC feature as offloading is done at NIC and as VLAN normally starts from 1, it may be a NIC issue when calculating checksums. DPDK has no concept of protocols. If you don't need the validation, then I guess you may be able to work without any offloading On Tue, May 18, 2021 at 11:47 AM Jagan P <jagan2.p@altran.com> wrote: > Please find the update below. > > > > What NICs are you using? Now need to understand the NIC limitations if any. > > >> The NIC we are using is “*82599ES 10-Gigabit SFI/SFP+ Network > Connection 10fb*". > > > > Yes, for vlan0 don't set checksum calculation offload and insert via > software but u won't get line rate for vlan0 > > >> Does this mean there is no support for vlan 0 in DPDK. Can this be > achieved in DPDK as there will be a compromise in performance when done in > software. > > > > First thing first do you need checksum validation at reciever? > > >> Actually we may not require checksum validation at receiver end. > Checksum on transmission alone is fine. But could you please explain the > reason behind this ask > > > > Thanks, > > Jagan P > > > > *From:* Muhammad Zain-ul-Abideen <zain2294@gmail.com> > *Sent:* Tuesday, May 18, 2021 12:23 AM > *To:* Jagan P <jagan2.p@altran.com> > *Cc:* users <users@dpdk.org> > *Subject:* Re: [dpdk-users] DPDK support for vlan id 0 > > > > ** This mail has been sent from an external source ** > > > > Good to hear. What NICs are you using? Now need to understand the NIC > limitations if any. > > Yes, for vlan0 don't set checksum calculation offload and insert via > software but u won't get line rate for vlan0.. need to toy around a bit . > > First thing first do you need checksum validation at reciever? > > > > On Mon, May 17, 2021, 11:32 PM Jagan P <jagan2.p@altran.com> wrote: > > Thanks a lot Muhammad for your inputs. > > > > We tried removing tx offloading in DPDK and now the packet is proper(IP > control flag and UDP dest port values). > > Attaching the packets for reference. > > > > Should we change any flag settings in mbuf’s ol_flags for vlan id 0 since > checksum offloading is proper for other vlans. > > > > Following flags are set for ol_flags to offload checksum. > > *L3 checksum:* > > PKT_TX_IPV4 and PKT_TX_IP_CKSUM Flags. > > > > *L4 checksum:* > > PKT_TX_IPV4, PKT_TX_IP_CKSUM and PKT_TX_UDP_CKSUM for UDP packets. > > > > With the above flags rte_ipv4_phdr_cksum API is triggered > > > > *Port config:* > > {link_speeds = 0, rxmode = {mq_mode = ETH_MQ_RX_NONE, max_rx_pkt_len = > 9728, max_lro_pkt_size = 0, split_hdr_size = 0, offloads = 2, reserved_64s > = { > > 0, 0}, reserved_ptrs = {0x0, 0x0}}, txmode = {mq_mode = > ETH_MQ_TX_NONE, offloads = 2, pvid = 0, hw_vlan_reject_tagged = 0 '\000', > > hw_vlan_reject_untagged = 0 '\000', hw_vlan_insert_pvid = 0 '\000', > reserved_64s = {0, 0}, reserved_ptrs = {0x0, 0x0}}, lpbk_mode = 0, > rx_adv_conf = { > > rss_conf = {rss_key = 0x0, rss_key_len = 0 '\000', rss_hf = 0}, > vmdq_dcb_conf = {nb_queue_pools = (unknown: 0), enable_default_pool = 0 > '\000', > > default_pool = 0 '\000', nb_pool_maps = 0 '\000', pool_map = > {{vlan_id = 0, pools = 0} <repeats 64 times>}, dcb_tc = > "\000\000\000\000\000\000\000"}, > > dcb_rx_conf = {nb_tcs = (unknown: 0), dcb_tc = > "\000\000\000\000\000\000\000"}, vmdq_rx_conf = {nb_queue_pools = (unknown: > 0), > > enable_default_pool = 0 '\000', default_pool = 0 '\000', > enable_loop_back = 0 '\000', nb_pool_maps = 0 '\000', rx_mode = 0, pool_map > = {{vlan_id = 0, > > pools = 0} <repeats 64 times>}}}, tx_adv_conf = > {vmdq_dcb_tx_conf = {nb_queue_pools = (unknown: 0), dcb_tc = > "\000\000\000\000\000\000\000"}, > > dcb_tx_conf = {nb_tcs = (unknown: 0), dcb_tc = > "\000\000\000\000\000\000\000"}, vmdq_tx_conf = {nb_queue_pools = (unknown: > 0)}}, dcb_capability_en = 0, > > fdir_conf = {mode = RTE_FDIR_MODE_NONE, pballoc = RTE_FDIR_PBALLOC_64K, > status = RTE_FDIR_NO_REPORT_STATUS, drop_queue = 0 '\000', mask = { > > vlan_tci_mask = 0, ipv4_mask = {src_ip = 0, dst_ip = 0, tos = 0 > '\000', ttl = 0 '\000', proto = 0 '\000'}, ipv6_mask = {src_ip = {0, 0, 0, > 0}, > > dst_ip = {0, 0, 0, 0}, tc = 0 '\000', proto = 0 '\000', hop_limits > = 0 '\000'}, src_port_mask = 0, dst_port_mask = 0, > > mac_addr_byte_mask = 0 '\000', tunnel_id_mask = 0, tunnel_type_mask > = 0 '\000'}, flex_conf = {nb_payloads = 0, nb_flexmasks = 0, flex_set = {{ > > type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 > times>}}, {type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 > times>}}, { > > type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 > times>}}, {type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 > times>}}, { > > type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 > times>}}, {type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 > times>}}, { > > type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 > times>}}, {type = RTE_ETH_PAYLOAD_UNKNOWN, src_offset = {0 <repeats 16 > times>}}}, > > flex_mask = {{flow_type = 0, mask = '\000' <repeats 15 times>} > <repeats 24 times>}}}, intr_conf = {lsc = 0, rxq = 0, rmv = 0}} > > > > Thanks, > > Jagan P > > > > > > *From:* Muhammad Zain-ul-Abideen <zain2294@gmail.com> > *Sent:* Monday, May 17, 2021 8:59 PM > *To:* Jagan P <jagan2.p@altran.com> > *Cc:* users <users@dpdk.org> > *Subject:* Re: [dpdk-users] DPDK support for vlan id 0 > > > > ** This mail has been sent from an external source ** > > > > Remove all offloading at any side! > > U may set bytes of ipv4 flags to zero specially before sending out . And > also remove any type of rx tx offloading.. and share the port config on dpdk > > > > On Mon, May 17, 2021, 8:24 PM Jagan P <jagan2.p@altran.com> wrote: > > Please find the update below. > > 1) What are the trailing bytes at the end of UDP packets? > > >> Thank you will check it. > > > > 2) Are you reusing the buffer and/or initializing it correctly? > > >> Yes, we are re-using it. We are doing memset to zero of > rte_mbuf’s buf_addr. > > > > 3) What NIC features are you using i.e. tx offloading? (As VLAN 12 has > checksum calculated while VLAN 0 has not) > > >> Yes, we are doing tx offloading. From the packet > capture in wireshark, it looks like, IPV4 control flags and checksum are > swapped for vlan 0 alone. > > > > Try forcing these bytes zero before and after sending the packet to see > the impact > > >> Sorry, I am not getting this point. Which bytes you > are referring to? You mean not to do offloading and to set .offloads as > zero in rte_eth_conf? > > > > Thanks, > > Jagan P > > > > *From:* Muhammad Zain-ul-Abideen <zain2294@gmail.com> > *Sent:* Monday, May 17, 2021 5:32 PM > *To:* Jagan P <jagan2.p@altran.com> > *Cc:* users@dpdk.org > *Subject:* Re: [dpdk-users] DPDK support for vlan id 0 > > > > ** This mail has been sent from an external source ** > > > > Ok, it seems that there is some issue initializing the buffer and/or > freeing it after use. It is not a DPDK issue not regenerated. > > 1) What are the trailing bytes at the end of UDP packets? > > 2) Are you reusing the buffer and/or initializing it correctly? > > 3) What NIC features are you using i.e. tx offloading? (As VLAN 12 has > checksum calculated while VLAN 0 has not) > > Try forcing these bytes zero before and after sending the packet to see > the impact > > > > > > On Mon, May 17, 2021 at 4:45 PM Jagan P <jagan2.p@altran.com> wrote: > > Hi Muhammad, > > > > We are using a single node connected to spirent Testcenter application(to > send and receive traffic). > > The dpdk version used is 20.05 version. > > > > I have attached the packets captured in egress flow for vlan 0(vlan_0_pkt > file) and with a valid vlan(vlan 12 and 18 – vlan_12_18_static file). > > We printed the packet in *ixgbe_xmit_pkts* API for vlan 0 and 12 and the > captured dump is attached in “vlan_0 pkt_dump” file. > > > > We are sending IP packet with vlan tag along with UDP header. The packet > flow will be as below. > > ingress port(rte_eth_rx_burst) => firewall =>routing=> nhop lookup =>ARP > lookup => egress port pkt forwarding(rte_eth_tx_burst). > > > > We added packet dump before and after calling *rte_eth_tx_burst* API in > our application. The dump looks good. So we added packet dump in > *ixgbe_xmit_pkts* API as well to confirm whether the packet in proper in > driver and the packet is proper here as well. > > > > We are not sure why the IP control flags and UDP dest port values are > modified. Should we handle anything specifically for packets with vlan id 0 > in rte_mbuf structure? > > > > Please share us your thoughts on this. > > Please let us know if any details are needed further. > > > > Thanks, > > Jagan P > > > > *From:* Muhammad Zain-ul-Abideen <zain2294@gmail.com> > *Sent:* Monday, May 17, 2021 2:16 PM > *To:* Jagan P <jagan2.p@altran.com> > *Cc:* users@dpdk.org > *Subject:* Re: [dpdk-users] DPDK support for vlan id 0 > > > > ** This mail has been sent from an external source ** > > > > Kindly tell us more about the setup and which dpdk you are using. and what > is the packet life at sender and receiver. > > > > > > > > > > On Mon, May 17, 2021 at 1:01 PM Jagan P <jagan2.p@altran.com> wrote: > > Hi, > We were trying to forward packets with vlan id as 0. But the packet is > getting altered when we do so. > The IP flag and the destination port fields are getting changed. We doubt > if this is happening in DPDK because till the rte_eth_tx_burst API, the > packet is proper. > But the packet captured at the destination is altered. > Could you please let us know if there is support in DPDK for forwarding > packet with vlan id 0 or if we are missing something. > > Packet at rte_eth_tx_burst: > dump mbuf at 0x1706dad00, iova=0x1706dad80, buf_len=2304 > pkt_len=252, ol_flags=0xf0000000000181, nb_segs=1, port=0, vlan_tci=0, > ptype=0x211 > segment at 0x1706dad00, data=0x1706dae04, len=252, off=132, refcnt=1 > Dump data at [0x1706dae04], len=200 > 00000000: 00 10 94 00 00 05 00 01 02 03 04 05 81 00 00 00 | > ................ > 00000010: 08 00 45 00 00 EA 00 02 00 00 3F 11 00 00 02 02 | > ..E.......?..... > 00000020: 02 02 05 05 05 02 62 A4 62 A3 00 D6 0E F2 00 00 | > ......b.b....... > 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 000000A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 000000B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | > ................ > 000000C0: 00 00 00 00 00 00 00 00 > > Packet captured at spirent(destination): > 00 10 94 00 00 05 00 01 02 03 04 05 81 00 00 00 > 08 00 45 00 00 EA 00 02 6e fe 3F 11 00 00 02 02 > 02 02 05 05 05 02 62 A4 f5 f8 00 D6 0E F2 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > Thanks, > Jagan P > > ===================================================== > Please refer to https://northamerica.altran.com/email-disclaimer > for important disclosures regarding this electronic communication. > ===================================================== > > ===================================================== > Please refer to https://northamerica.altran.com/email-disclaimer > for important disclosures regarding this electronic communication. > ===================================================== > > ===================================================== > Please refer to https://northamerica.altran.com/email-disclaimer > for important disclosures regarding this electronic communication. > ===================================================== > > ===================================================== > Please refer to https://northamerica.altran.com/email-disclaimer > for important disclosures regarding this electronic communication. > ===================================================== > > ===================================================== > Please refer to https://northamerica.altran.com/email-disclaimer > for important disclosures regarding this electronic communication. > ===================================================== > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2021-05-20 8:01 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-05-12 15:40 [dpdk-users] DPDK support for vlan id 0 Jagan P 2021-05-17 8:45 ` Muhammad Zain-ul-Abideen 2021-05-17 11:45 ` Jagan P 2021-05-17 12:02 ` Muhammad Zain-ul-Abideen 2021-05-17 15:24 ` Jagan P 2021-05-17 15:28 ` Muhammad Zain-ul-Abideen 2021-05-17 18:32 ` Jagan P 2021-05-17 18:52 ` Muhammad Zain-ul-Abideen 2021-05-18 6:47 ` Jagan P 2021-05-18 8:46 ` Muhammad Zain-ul-Abideen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).