DPDK usage discussions
 help / color / mirror / Atom feed
From: Jagan P <jagan2.p@altran.com>
To: Muhammad Zain-ul-Abideen <zain2294@gmail.com>
Cc: "users@dpdk.org" <users@dpdk.org>
Subject: Re: [dpdk-users] DPDK support for vlan id 0
Date: Mon, 17 May 2021 15:24:24 +0000	[thread overview]
Message-ID: <MAXPR01MB327890A63FAA27FF34CF057BDC2D9@MAXPR01MB3278.INDPRD01.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <CAN7yQ2o=gje_k3O=LT_L3B29L1VE7kvfhGM9Fz-Jq8rkM4Z5KQ@mail.gmail.com>

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.
=====================================================

  reply	other threads:[~2021-05-18  6:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-12 15:40 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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MAXPR01MB327890A63FAA27FF34CF057BDC2D9@MAXPR01MB3278.INDPRD01.PROD.OUTLOOK.COM \
    --to=jagan2.p@altran.com \
    --cc=users@dpdk.org \
    --cc=zain2294@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).