DPDK usage discussions
 help / color / mirror / Atom feed
* [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

DPDK usage discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/users/0 users/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 users users/ https://inbox.dpdk.org/users \
		users@dpdk.org
	public-inbox-index users

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.users


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git